On Wed, May 05, 2004 at 08:12:24PM -0400, Austin Hastings wrote: : Apparently the AUTOMETH code will be invoked to determine what code matches : a request. AUTOMETH will "return a reference to" a matching method. This : implies that AUTOMETH is expected to resolve dispatch within the class -- : "Here is the best answer I know."
No, the intent of AUTOMETH is merely to indicate that the name might be resolved by this class somehow. But I see your point that not all dispatchers want a single answer. The discussion of AUTOMETH was written primarily with single dispatch in mind, but it would be pretty easy to generalize AUTOMETH to return a list of candidates if the "name" in question is wildcardish in some fashion. : This seems an awkward way to implement dispatch, since the price of using : AUTOMETH is being able to write a method dispatcher -- there won't be many : one-line AUTHMETH methods. : : Also, it precludes having multiple candidates from a single source -- like : most "playoff" systems (but not the BCS :-). : : Given that we've got a signature mechanism, it should be straightforward to : "declare" to dynwhat methods a class/role will respond. Thus, instead of a : interviewing a network of classes, the dispatcher could collect the data and : massage it in an appropriate fashion. I don't see how that's terribly different from what A12 is feebly attempting to say. It's all very well to supply dynamic declaration, but if you don't have a logical time to call it, it doesn't do you much good. AUTOMETH is designed to be called at dispatch time, when you already have a spec for the method you want to call. The only earlier dynamic time to declare methods that makes much sense to me is class composition time, and we have other mechanisms for declaring methods at that time. : This has the side-benefit of solving my problem nicely: I can "declare" the : names to which I will respond, so that in(tro)spection will produce the : desired result, and so that invalid calls to my class can be caught before : being dispatched -- either at compile time or earlier in the runtime cycle. : (Even if they are only caught at runtime, they will at least be caught by : Perl itself rather than falling out the bottom of my switch statement.) : : Comment? I think you might be missing the fact that the reference (or references, for multimethod dispatch) returned by AUTOMETH is not necessarily a reference to a defined method. It will often be a reference to a stub that is later resolved by an AUTOMETHDEF or a delegation. You need the method stub anyway to hold the properties on which your metadata is predicated. Except for performance reasons, it would be silly for the class to store method metadata redundantly when it can just keep a list of the method objects themselves, whether or not those method objects are defined or merely declared. On the other hand, it could simply be that I don't understand what you're asking for. Stranger things have happened... Larry
