develooper Front page | perl.perl5.porters | Postings from October 2007

Re: [perl #46987] OO-call failures, autoviv-functions & testing theirexistence

Thread Previous | Thread Next
From:
Sam Vilain
Date:
October 30, 2007 07:16
Subject:
Re: [perl #46987] OO-call failures, autoviv-functions & testing theirexistence
Message ID:
47273CAF.5030307@vilain.net
demerphq wrote:
> On 10/30/07, Sam Vilain <sam@vilain.net> wrote:
>   
>> I for one agree that the default ->can() should only return true if
>> there is a method that is callable.  Instead of just looking for the
>> CODE slot in the Glob with "exists", it should check "defined".  Modules
>> that expect ->can() to work on a more "exists"-like check, and fudge the
>> rest with AUTOLOAD /should/ be defining their own ->can().  I have no
>> idea how many modules make use of this current behaviour.
>>     
>
> Except that things work just fine if they are using autoload without
> needing to overload can.
>   

Ok I think I now agree for overload classes this is a reasonable thing
to do. 

However for other classes if the CV is undef it's pretty much guaranteed
that ->can() is going to return the wrong answer.

eg

 perl -le '{
  package X;sub n{bless{},X};\&y}
  package main;my$x=X->n;
  print $x->can("y")||0;
  $x->y'

Perhaps this could have a warning for it?

> > As far as methods vs functions goes, well that's a slightly more daring
> > change.  Obviously it's in the Perl 6 definition, which means that it's
> > not completely out of the question for a later 5.x release.  It's just
> > very hard to specify how the language could change to cater for it.
> > For instance, if the current "CODE" glob slot was extended to allow
> > "METHOD" and "FUNCTION", backwards compatibility could be maintained, to
> > some degree at least.  But then you've also got the question of
> > multimethods and methods that have particular type signatures - again,
> > calling for a prototype on CPAN first before anything is considered for
> > being a language change.
> 
> Its not only an issue of internals, its also an issue of syntax. How
> would we denote these methods? How would they impact on back-compat?
> Would it just make things more complex for little gain by having the
> OO mechanism work with CODE *and* with METHOD? After all the existing
> code still has to work.

This is a similar problem to the one Class::MultiMethods solves.  The thing
that lives in the CODE slot is a run-time dispatcher to METHOD or FUNCTION
based on the context it finds itself in.  Eminently prototypable :)

> Basically its just an issue that Perls OO is a
> pretty loose framework for associating data structures with the
> methods that operate on them with a few token gestures towards
> inheritance and overloading. If you expect perls OO to work the way it
> works in a static language with first class objects then you will find
> yourself surprised on occasion.

Sure, agreed.

> OTOH If you ignore how other languages
> do OO then Perls OO is just fine.

I don't want to completely ignore Perl 6 :)

Sam


Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About