> > When you want to turn off an inherited delegation in an ISA situation?
>
> Um, I don't think I understand the question.
I'm confused by the question, too.
> Delegation is not inherited. Any module you inherit from you won't
> use for delegation, AFAIK. They're two differe
"David L. Nicol" wrote:
>
> When you want to turn off an inherited delegation in an ISA situation?
Um, I don't think I understand the question. Delegation is not
inherited. Any module you inherit from you won't use for delegation,
AFAIK. They're two different beasts.
Or am I misunderstanding yo
When you want to turn off an inherited delegation in an ISA situation?
"David E. Wheeler" wrote:
>
> Damian Conway wrote:
>
> > Err, that *is* the default behaviour. Delegation doesn't occur unless
> > you specify it. Or am I missing your meaning here?
>
> use delegation
> attr1 =>
> use delegation
> attr1 => [qw( method1 method2 method3 )],
> attr2 => [qw( method4 method5 )],
> attr3 => __ALL__, # Use all of them.
> attr4 => []; # Use none of them.
>
> Yes, I realize that not putting attr4 in there at all is the same
> (default)
Damian Conway wrote:
> Err, that *is* the default behaviour. Delegation doesn't occur unless
> you specify it. Or am I missing your meaning here?
use delegation
attr1 => [qw( method1 method2 method3 )],
attr2 => [qw( method4 method5 )],
attr3 => __ALL__, # Use all of them.
attr4
> >> This way, I know that an empty arrayref means "all methods"
> >> rather than "none."
> >
> > Kinda redundant since that's the default behaviour, but perhaps
> > useful as a documentation mechanism.
>
> Unless you change the default behavio[u]r to "don't delegate
Damian Conway wrote:
>
> Stupid, stupid, stupid! Of course, that should be:
>
> attr3 => __ALL__
>
> and then delegated methods can be named any(crazy)thing.
Damn, Damian, don't be so hard on yourself! You're right about __ALL__,
of course, but I suspect that most of us would have a pr
Damian Conway wrote:
> It was (and is) a good suggestion. I suspect however that it should be
>
> attr3 => [__ALL__]
>
> so that classes can still have an C method delegated.
> (Yes, now they can't have an C<__ALL__> method,
> but maybe that's a Good Thing ;-)
Agreed. Yes, that's very goo
Damian Conway wrote:
>
>> attr3 => [ALL]
>
> It was (and is) a good suggestion. I suspect however that it should be
>
> attr3 => [__ALL__]
Any consideration given to the :all export-like tag?
attr3 => [:all]# could be uppercase too
-Nate
Too early in the morning, I wrote:
>> I might like to see something like URI suggested:
>>
>> attr3 => [ALL]
>
> It was (and is) a good suggestion. I suspect however that it should be
>
> attr3 => [__ALL__]
>
> so that classes can still have an C
> When I see those empty arrayrefs, I think "delegate to *no* methods in
> those classes stored in attr3 and att4," rather than "delegate all
> method calls to those attributes." Just in the name of greater clarity,
> I might like to see something like URI suggested:
>
> attr3
> Is this not just a module which creates the necessary subs in the calling
> package ? The catchall can be done with an AUTOLOAD sub.
That's certainly how Class::Delegation is implemented.
It isn't quite adequate however, because if you trigger the AUTOLOAD and
it *fails* to delegate, you
Perl6 RFC Librarian wrote:
>
> This and other RFCs are available on the web at
> http://dev.perl.org/rfc/
>
> =head1 TITLE
>
> Objects : Core support for method delegation
This idea rocks, Damian! I want it now! Just one suggestion, however...
> The proposed delegation mechanism would work
On Mon, Sep 04, 2000 at 09:53:39PM -, Perl6 RFC Librarian wrote:
> The proposed delegation mechanism would work via a pragma:
>
> use delegation
> attr1 => [qw( method1 method2 method3 )],
> attr2 => [qw( method4 method5 )],
> attr3 => [],
>
Michael G Schwern <[EMAIL PROTECTED]> writes:
> On Mon, Sep 04, 2000 at 09:53:39PM -, Perl6 RFC Librarian wrote:
> > Objects : Core support for method delegation
>
> I like it! One gripe (of course)...
>
>
> > The proposed delegation mechanism would work via a pragma:
> >
> > use del
Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
> This and other RFCs are available on the web at
> http://dev.perl.org/rfc/
>
> =head1 TITLE
>
> Objects : Core support for method delegation
I *want* this. Delegation is cool. Delegation that gets set up at
compile time and is marked as such
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
PRL> use Class::Delegation
>>
>> shouldn't that be use delegation? i think you have a cut and paste
>> error.
DC> You're correct. Many thanks.
DC> (That's what I get for pre-testing all the code in my RFCs! ;-)
heh, you should
On Mon, Sep 04, 2000 at 09:53:39PM -, Perl6 RFC Librarian wrote:
> Objects : Core support for method delegation
I like it! One gripe (of course)...
> The proposed delegation mechanism would work via a pragma:
>
> use delegation
> attr1 => [qw( method1 method2 method3 )
> PRL> One powerful application of delegation is as a replacement for
> PRL> inheritance where the internals of a prospective base class are
> PRL> inaccessible or inconvenient, or the base class was not designed
> PRL> to be inherited and yet it must be.
>
> isn't this
> "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
PRL> One powerful application of delegation is as a replacement for
PRL> inheritance where the internals of a prospective base class are
PRL> inaccessible or inconvenient, or the base class was not designed
PRL> to be inherit
20 matches
Mail list logo
