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

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

Thread Previous | Thread Next
Sam Vilain
October 29, 2007 23:16
Re: [perl #46987] OO-call failures, autoviv-functions & testing theirexistence
Message ID:
Linda W wrote:
> 	Your explanation is based in Perl's internals.  A bug in
> Perl's internals implementation is not supporting evidence for
> why documented OO calling functionality should be broken.

What you are referring to as the "internals" is actually well documented
interface.  The Symbol table, much as some people like to call that
internals, is every much a part of the language as any other part.  It
even has its own sigil.  Taking a reference to a hash slot, for
instance, will "vivify" that hash slot.  This is defined interface,
though it is partially motivated by the pragmatic concern to build an
interface that matches the implementation.  The same auto-vivification
is happening here.

> 	Current implementation aside, do you really believe the current
> implementation ("can" unreliable, and local-undef-funcs supersede parent
> method calls) serves *any* valid or reasonable purpose.  Can you put
> the current implementation aside and think or converse with OO
> experts (not other perl-internal experts). About the functionality
> as is and as suggested from a "functional" (within an Object Oriented
> Context) point of view?

I think as someone who makes most people's eyes glaze over whenever I
talk about schemas and metamodels, that I qualify as an OO expert.  So,
here we are, let's talk.

I've scanned over a couple of your e-mails, and I think that you have a
few valid points.  Not that my opinion is particularly weighty, not
being a porter and all.

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.

I think the thing to do would be to knock up a patch to UNIVERSAL::can
and see how much of CPAN that change breaks.  You can release this onto
CPAN so that you can have a dependency that patches the running Perl to
behave as you expect.  See the existing UNIVERSAL::can and
UNIVERSAL::isa distributions, you can release it as something else that
just assigns to *UNIVERSAL::can.  If you observe that not much breaks,
then it can be considered for inclusion.  "All's fair if you
pre-declare" they say, so this might need a 'use feature' or equivalent
to change this behaviour.

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.

Anyway, in summary, a prototype is worth a thousand flamewars, so I'd
suggest that you consider what can be implemented, try to do so and come
back with your results.

You may be interested in collaborating with Gerard Goosen, as he is
attempting instead of keeping Perl compatible with CPAN to port the best
parts of CPAN with Perl, freeing the language to evolve more freely.
Perhaps he will be willing to entertain such a change in Kurila Perl.

Good luck,

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