Damian Conway <[EMAIL PROTECTED]> writes:
> Thanks for getting this RFC together, Piers.
>
> A few comments:
>
> * I suggest you remove my alternative C<:must(Foo)> suggestion.
> It's too ugly to live, inless you just want to use it as a
> scare tactic to encourage Larry to chose the C<interface>
> syntax instead ;-)
I'll get rid of it and reference the message where you propose the too
ugly to live syntax.
> * The new C<interface> keyword would be unnecessary if *package
> specifications* could take attributes:
>
> interface Fetcher;
>
> would then become:
>
> package Fetcher : interface;
New RFC threatened: "Attributes everywhere and damn the
implementation." Damian can write it.
> * There's also no need to distinguish C<use base> and C<use interface>,
> since you've previously distinguished them by keyword. I would
> suggest that either C<use base> be used for both types of
> inheritance, or else the definition of an interface specification
> just be a regular C<package>.
I dunno. I like the Javaesque distinction between a class *being* a
Dog and *implementing* Fetcher. Sure it's syntactic sugar, but I think
it's good sugar.
> * Interfaces will also need to honour C<use delegation>
> (RFC 193), which provides yet another way of *not* actually
> specifying a method, yet still having it callable.
I'm not sure that this needs to go into the body of the RFC. I'll
stick it on as a reference with a note to the effect that if 'use
delegation' gets implemented then interfaces will have to take note.
>
>
> * The C<use deferred> pragma seems unnecessary, as it is sufficient
> to *declare* the autoloaded method, rather than *define* it.
> That is:
>
> use deferred 'rollover';
>
> is really just:
>
> sub rollover;
>
> BTW, this trick already works in Perl 5 (for making C<can>
> acknowledge autoloaded methods).
Hmm... point taken. Though I do think C<use deferred> could be looked
upon as a vaguely nice bit of syntactic sugar...
--
Piers
