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

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

Thread Previous | Thread Next
October 30, 2007 04:18
Re: [perl #46987] OO-call failures, autoviv-functions & testing their existence
Message ID:
On 10/30/07, Sam Vilain <> 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.

> 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.

Personally I don't see the need, unless we are going to make "first
class" objects part of the language, and I don't see that as being
particularly feasible.  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. OTOH If you ignore how other languages
do OO then Perls OO is just fine.


perl -Mre=debug -e "/just|another|perl|hacker/"

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About