-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Moin.

On Friday 02 March 2007 08:53:43 demerphq wrote:
> On 3/2/07, Adam Kennedy <[EMAIL PROTECTED]> wrote:
> > > 99.999% of the time you do not want to really know how something is
> > > implemented, you want to remain ignorant.
> >
> > I concur, which is what really pisses me off them
> > IO::String->new(\$string)->isa('IO::Handle') returns false, because the
> > author believes in duck typing over actually having isa describe the
> > interfaces.
>
> This comment lead to do some thinking about perls typing and OO
> structure and why people seem to have a lot of trouble agreeing on
> things like this.
>
> A "type" in a language like C is a specification of data
> representation in memory.
>
> In an OO language like C++ this gets extended to be a data
> representation in memory plus a set of methods that represents an
> interface.
>
> But...
>
> In Perl the memory organization is orthagonal to the interface.
>
> So we have immutable types like SV's, AV's,HV's, CV's, FORMATS, IO, etc.
>
> And then through blessing we can associate the same set of methods to
> any or all of those types.
>
> So when you try to fit the Perl model into the C++ model something has to
> give.
>
> The only way to properly map the perl level concepts to C++ is to say
> that a C++ type is a perl type+a perl class.
>
> But because of the history of ref(), and isa() and the way 'type' is
> misused in the perl literature the distinction is blurred. Some people
> want to say "are you something I can deref as a particular type AND
> has an interface I know how to use" and some people JUST want to say
> "are you something that has an interface I know how to use". Both
> questions are reasonable and mutually exclusive. One routine cant do
> both.
>
> So for instance to me it seems to reasonable for IO::String to say, no
> I am not a IO::Handle. Its data representation doesnt use a IO object
> so its not an IO::Handle, even if it does provide the same method
> interface.

This is the same as me writing a subclass from Foo, then modifying isa() to 
say "no, I am not a Foo. I just re-use 95% of it's code, but I am really 
not providing the same interface".

And so when someone asks Bar->isa('Foo'), the get the right answer.

I really don't know why someone (except people writing things like 
Data::Dumper) would want to peak under the hood of Bar and discern whether 
it really is (almost) a Foo, or not.

> isa() is to some a method that asks the first question, but to others
> is asks the second question.
>
> Now if there was an ->implements() utility function as well as the
> ->isa() funcation, then I think IO::Handle would contrive to ensure
> that IO::String->new(\$string)->implements('IO::Handle') would return
> true even though IO::String->new(\$string)->isa('IO::Handle') would
> not. (Im not sure if this is the same as chromatics proposed 'does'
> function).

I am not sure why you would have the need for an implements() or does() 
function. Either the interface is complete (e.g. Bar "is a" Foo), or it 
isn't, then Bar isn't a Foo. In the latter case you can only check if 
certain methods are there, and we already have can() for that.

What would does() or implement() do differenly? Tell you that Bar implements 
a method just like Foo() does?

All the best,

Tels

- -- 
 Signed on Fri Mar  2 11:21:18 2007 with key 0x93B84C15.
 Get one of my photo posters: http://bloodgate.com/posters
 PGP key on http://bloodgate.com/tels.asc or per email.

 "We have problems like this all of the time," Kirk said, trying to
 reassure me.  "Sometimes its really hard to get things burning."

  -- http://tinyurl.com/qmg5
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iQEVAwUBRegJj3cLPEOTuEwVAQLOfQf9HAK5Q0W6myPPcaVqheUV20eQXFb+nw97
9tm407RJAa3FZtW5A8wjHhB7r5NpkFnX0ye6Y8eFC4I2rH2ENyM5EklAnjK0udok
FoO64ERgaQNSEiRFbP80naCEM713DibbBCngoyRPML/N0ob1JvPpl0HSm+bj1h4R
p/jbkqK+eOghG23ZQt6lBJ5gDA14Mfm2xmyJxrwElExu6qKhrO5oTSutKovfjYax
qjHvIVOpZS1WqByj/KYNLu9NYM/n45Sh5CXqKD2wvZvxoJ2xWEsYE4ikLjExlS1z
ahGMimto2y6yV9RDiW1Hkb0CkgJlDF0PWmUQEYC9beYKPfKJS7NcKg==
=QFWh
-----END PGP SIGNATURE-----

Reply via email to