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
From:
demerphq
Date:
October 30, 2007 04:18
Subject:
Re: [perl #46987] OO-call failures, autoviv-functions & testing their existence
Message ID:
9b18b3110710300417i1c79b511l40a551f5a0b1371e@mail.gmail.com
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.

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

Cheers,
yves

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

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