> -----Original Message-----
> From: Larry Wall [mailto:[EMAIL PROTECTED]
> Sent: Friday, 07 May, 2004 12:40 PM
> To: Perl6 Language
> Subject: Re: Specifying class interfaces with AUTOMETH
>
> : 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.
I agree: classes have a chance to pre-specify the class
signatures, and objects get a chance to dynamically agree to
undertake method calls.
The timeframe I was thinking of was object construction 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.
I'm not sure what the "metadata" would be, but I don't think
I missed anything regarding the characteristics of the reference
returned by AUTOMETH -- I had assumed that AUTOMETH returned
what was needed to continue execution.
>
> On the other hand, it could simply be that I don't understand
> what you're asking for. Stranger things have happened...
What I'm looking for is a concrete class signature.
That is, I want an external entity to be able to inspect the
class, or an object of the class, and KNOW what methods are
supported.
If the coder wants to implement everything via AUTOMETH and not
tell me, that's okay.
But if I was told what methods a class supports, I want to be able
to manufacture a proxy for that class that supports the same
methods, maybe a few more mixed in, and will report that concrete
signature when inspected:
4x:
class Dog {
method bark {...}
method grow {...}
method scratch {...}
method sniff {...}
method walk {...}
method hunt {...}
}
class prOxyGen
{
role proxy {...}
method new($what)
{
$class = get_class($what);
$proxy = new MetaClass($class.name);
$proxy.does(proxy);
for $class.meta.methods() -> $method {
$proxy.add_method($method)
unless $method ~~ 'hunt';
}
return $proxy;
}
}
If I say:
my Dog $spot = new Dog('Spot');
my $gettysburg_address = new prOxyGen($spot);
I want to be able to query $spot and get a list of public methods.
I want to be able to query $rover and get a similar list.
I *do not* want the signature for the proxy class to look like
"stuff added by the proxy role, plus AUTOMETH".
> Larry
=Austin
