* Rafael Garcia-Suarez <rgarciasuarez@gmail.com> [2008-05-07 09:35]: > use overload '->' => \&invoke; # more graphic ? ++ > * that would work only for instance methods, not class methods I think Ricardo considers that a feature; I can see that point of view, but perosnally I’m not sure yet. I think it would be nice if there was a way to get both, but separately from each other. > * that would step over AUTOLOADed methods -- AUTOLOAD would > never be called in presence of -> overloading Which is OK, since it can do everything AUTOLOAD can, and then some. > * would that step over regular, existing, defined methods ? > If it doesn't, we can instruct invoke() to install new > methods, à la AUTOLOAD. I think sometimes you’d want it to and sometimes wouldn’t. Maybe an option à la `fallback` that lets you pick which behaviour you would prefer in this instance. Not sure what the default should be though. > * We will need to avoid calling methods on the same object from > inside invoke(), to avoid deep recursion. You just need to make sure the recursion bottoms out; same as using recursion in any other scenario. > * What if someones invokes the "(->" method directly ? (the > internal name of "invoke()".) Maybe all overload methods > (whose names begin with "(") should be excluded from this > mechanism. I’m not sure about `(->` specifically, but why exclude the other methods? If we assume that unusual dispatch rules are sometimes useful, wouldn’t this mean that unusual dispatch rules for op handlers would also sometimes be useful? > * We will probably want a nice way to throw the error "Can't > locate object method %s via package %s", like a new builtin, > or a core function in the overload package That would be nice to have anyway – I’ve emulated that message in at least half of the (few) AUTOLOADs I’ve written. > * Of course, subclasses will inherit that overloading. Sounds good to me. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>Thread Previous | Thread Next