Prev: Can not intercept and disable MouseWheel on a canvas
Next: How to ignore newline in Parse::RecDescent
From: brian d foy on 26 Apr 2010 13:47
In article <q3rea7-dt91.ln1(a)osiris.mauzo.dyndns.org>, Ben Morrow
<ben(a)morrow.me.uk> wrote:

> Quoth brian d foy <brian.d.foy(a)gmail.com>:
> > In article <qma4a7-scj2.ln1(a)osiris.mauzo.dyndns.org>, Ben Morrow
> > <ben(a)morrow.me.uk> wrote:
> > >
> > > Should this answer mention ->DOES at this point? AIUI, most of the time
> > > it's a more appropriate test than ->isa, but I must admit I'm not
> > > entirely clear on the difference between the two.
> >
> > Yes, that should be DOES now.
> >
> > The difference between the two is that isa() checks for inheritance
> > while DOES() checks that the object performs a role despite
> > inheritance. Roles, traits, and mixins want to provide functionality
> > without inheritance.
>
> Yes, but when do you care? If an object conforms to a given interface,
> what difference does it make (from outside the object) whether those
> methods are implemented through inheritance, delegation, mixins, or
> whatever?

Well, you care when you need to check for the ability to handle a role.
You can't do that with isa() because it's not an inheritance
relationship. isa() implies an implementation detail, while DOES() does
not.
From: Ben Morrow on 26 Apr 2010 16:49

Quoth brian d foy <brian.d.foy(a)gmail.com>:
> In article <q3rea7-dt91.ln1(a)osiris.mauzo.dyndns.org>, Ben Morrow
> <ben(a)morrow.me.uk> wrote:
>
> > Quoth brian d foy <brian.d.foy(a)gmail.com>:
> > > In article <qma4a7-scj2.ln1(a)osiris.mauzo.dyndns.org>, Ben Morrow
> > > <ben(a)morrow.me.uk> wrote:
> > > >
> > > > Should this answer mention ->DOES at this point? AIUI, most of the time
> > > > it's a more appropriate test than ->isa, but I must admit I'm not
> > > > entirely clear on the difference between the two.
> > >
> > > Yes, that should be DOES now.
> > >
> > > The difference between the two is that isa() checks for inheritance
> > > while DOES() checks that the object performs a role despite
> > > inheritance. Roles, traits, and mixins want to provide functionality
> > > without inheritance.
> >
> > Yes, but when do you care? If an object conforms to a given interface,
> > what difference does it make (from outside the object) whether those
> > methods are implemented through inheritance, delegation, mixins, or
> > whatever?
>
> Well, you care when you need to check for the ability to handle a role.
> You can't do that with isa() because it's not an inheritance
> relationship. isa() implies an implementation detail, while DOES() does
> not.

I'm not being clear, I think. What I want to know is

Under what circumstances is it *correct* for $obj->DOES("Foo") to
return true but *incorrect* for $obj->isa("Foo") to return true?

If ->isa is restricted to only checking @ISA for inheritance, then why
is it overridable? Does this mean that modules like Test::MockObject
which return true from ->isa for classes they don't 'inherit' from (via
@ISA) are acting incorrectly?

Ben

From: Xho Jingleheimerschmidt on 26 Apr 2010 23:52
brian d foy wrote:
> In article <qma4a7-scj2.ln1(a)osiris.mauzo.dyndns.org>, Ben Morrow
> <ben(a)morrow.me.uk> wrote:
>
>> Quoth PerlFAQ Server <brian(a)theperlreview.com>:
>>> Most of the time, you shouldn't care what package an object is blessed
>>> into, however, as long as it claims to inherit from that class:
>>>
>>> my $is_right_class = eval { $object->isa( $package ) }; #
>>> true or false
>> Should this answer mention ->DOES at this point? AIUI, most of the time
>> it's a more appropriate test than ->isa, but I must admit I'm not
>> entirely clear on the difference between the two.
>
> Yes, that should be DOES now.
>
> The difference between the two is that isa() checks for inheritance
> while DOES() checks that the object performs a role despite
> inheritance. Roles, traits, and mixins want to provide functionality
> without inheritance.

Maybe this is just because I have to read the documentation on the web
(don't have a local 5.10 install), but I can't find where this is
documented. In places I've seen it say that DOES and isa *by default*
give the same answer. Where does it say how one departs away from this
default?

Xho
From: Ben Morrow on 27 Apr 2010 08:59

Quoth Xho Jingleheimerschmidt <xhoster(a)gmail.com>:
> brian d foy wrote:
> > In article <qma4a7-scj2.ln1(a)osiris.mauzo.dyndns.org>, Ben Morrow
> > <ben(a)morrow.me.uk> wrote:
> >
> >> Quoth PerlFAQ Server <brian(a)theperlreview.com>:
> >>> Most of the time, you shouldn't care what package an object is blessed
> >>> into, however, as long as it claims to inherit from that class:
> >>>
> >>> my $is_right_class = eval { $object->isa( $package ) }; #
> >>> true or false
> >> Should this answer mention ->DOES at this point? AIUI, most of the time
> >> it's a more appropriate test than ->isa, but I must admit I'm not
> >> entirely clear on the difference between the two.
> >
> > Yes, that should be DOES now.
> >
> > The difference between the two is that isa() checks for inheritance
> > while DOES() checks that the object performs a role despite
> > inheritance. Roles, traits, and mixins want to provide functionality
> > without inheritance.
>
> Maybe this is just because I have to read the documentation on the web
> (don't have a local 5.10 install), but I can't find where this is
> documented. In places I've seen it say that DOES and isa *by default*
> give the same answer. Where does it say how one departs away from this
> default?

They are both methods, so they depart from the default when a class
overrides them. This is why they should never be called as functions.

Ben

From: brian d foy on 27 Apr 2010 17:07
In article <braha7-clj1.ln1(a)osiris.mauzo.dyndns.org>, Ben Morrow
<ben(a)morrow.me.uk> wrote:


> I'm not being clear, I think. What I want to know is
>
> Under what circumstances is it *correct* for $obj->DOES("Foo") to
> return true but *incorrect* for $obj->isa("Foo") to return true?

It's incorrect for isa() to return true if the module does not inherit
from the thing you give it, although DOES() can return true when it
does the role without inheriting from it.

I understand your question, but I don't think you're seeing the
difference between inheritance and roles.


> If ->isa is restricted to only checking @ISA for inheritance, then why
> is it overridable?

Because Perl is a dynamic language and that's only a normal method. If
something wants to claim to inherit from something for whatever reason,
well, Perl lets you do that. I'm not saying it's a good idea, just that
it is what it is.
First  |  Prev  | 
Pages: 1 2
Prev: Can not intercept and disable MouseWheel on a canvas
Next: How to ignore newline in Parse::RecDescent