"DEFINE YOUR API YOU LAZY SOD!"

[kraih]

While i have to agree with @stevan that the old AUTOLOAD api in Perl is horrible, i believe some implementation of the concept is necessary. If not for new modules, at least for ports of existing ones. The Ruby implementation (method_missing) is not too bad. http://ruby-doc.org/core-2.0.0/BasicObject.html#method-i-method_missing

[tobyink]

Ideally an autoload replacement should, rather than executing the missing method, either return the method as a coderef, or return undef, or die.

Why?

• $obj->can($methodname) can easily hook into this.
• after the first time method_missing been called, the coderef can be cached for later re-use if the missing method is called again.
• an undef response allows mop to walk further up the inheritance hierarchy looking for method_missing in superclasses, and only fail if none reponds with a coderef.

[doy]

Maybe the hook for this should actually be just overriding can?

[stevan]

@doy only if I can have auto-deref back :P

[stevan]

We should look into Class::Std and AUTOMETHOD somewhat, seems similar to what we are talking about (https://metacpan.org/pod/Class::Std#Methods-that-can-be-supplied-by-the-developer)

[doy]

Yeah, although I don't particularly like the magical "call every AUTOMETHOD" thing - there's no reason here why the user can't just return $self->next::method. Especially since with that modification, AUTOMETHOD becomes identical to can(:

[stevan]

@doy - Agreed, we can make forwarding to the parent the responsibility of the user I think that is fair. Although, the "call every $x" is similar to BUILD and DEMOLISH, this would just be AUTOMETHODALL.

[doy]

My main issue is that I don't think the *ALL structure works quite as well for methods that return a value.

[stevan]

I can appreciate that.