develooper Front page | perl.perl5.porters | Postings from November 2003

Re: [5.8.12] Proposal for changing UNIVERSAL semantics

Thread Previous | Thread Next
Michael G Schwern
November 4, 2003 15:52
Re: [5.8.12] Proposal for changing UNIVERSAL semantics
Message ID:
I'm done with this issue, answering point-by-point is taking up too much
time for such a small thing.  So I'll just sum up.

A) UNIVERSAL::AUTOLOAD module on CPAN for coordinating multiple modules that
use U::A in the same process, good idea.  Of all the things to plop into
UNIVERSAL, AUTOLOAD is the one most fraught with peril.  Do it.  Once done, 
grep CPAN (or I can do it for you) for uses of UNIVERSAL::AUTOLOAD and 
contact the authors about your new module.  I'm sure they'll be happy to use 

There's no point putting it in the core.  Its too dangerous. 
    * likely to cause *more* problems by expanding the
      methods in, no matter how hard they try to be
    * folks will have to wait around for 5.10 to use it
    * users will have a 5.10 depenency
    * becomes p5p's problem to maintain
    * creates an "official" solution to the problem where no such status is 
      necessary or desirable.  It should stand on its merits, not fiat.
    * its simple enough to find the users of UNIVERSAL::AUTOLOAD and contact
      them individually to get the word out
    * Goes against the de-facto policy of only introducing new modules to
      the core if they help install more modules.

B) Changing UNIVERSAL::can() to not report inherited UNIVERSAL methods: Bad.
It breaks backward compatibility for very little gain.  Going through the 
likely two to four year deprecation cycle is not worth it.
  * Doesn't actually solve the design issues inherent in UNIVERSAL, only 
    obscures one possible method for falling afoul of UNIVERSAL.
  * Assumes that when people use can() they don't want to know about
    stuff in UNIVERSAL.  This assumption cannot be made and contradicts the
    documentation of both UNIVERSAL and can().  Everyone inherits from
    UNIVERSAL.  can() reports if a method can be called.  If UNIVERSAL
    implements a method, can() should always be true for that method.
  * Addresses a small edge case when there's similar and much more
    widespread cases (ie. the DynaLoader AUTOLOAD hole) that are handled
    just fine without changing the behavior of can().
  * Doesn't even truely solve the problem but just obscures its existence
    IF you happen to be using can() to detect method existence before calling
    it.  Otherwise it has no effect.

Perl has a very, very promiscuous inheritence model.  No function can ever
be truely private.  Even imported functions are inherited.  This problem
effects *all* OO code in Perl 5.  We live with these "flaws" every day. 
UNIVERSAL is just special in that it piles its own promiscuity on top of it.

I wish we could fix this, but we can't.  Trying to fix the one special
case caused by UNIVERSAL is just plugging one hole in a sieve.  The Perl 6
language list is thataway.

You have to be very careful when touching the shared space of UNIVERSAL or
using any UNIVERSAL module to avoid pollution.  We recently had a long 
argument about Class::DBI using UNIVERSAL::moniker over on cdbi-talk.
Altering can() doesn't change this.

Finally, UNIVERSAL is a deliberate *FEATURE* of Perl's OO design.  Its
promiscuity is by design.  Like it or not, its Perl.

In the end, I'm not pumpking so this is just all my opinion.

Michael G Schwern
<mendel>	 ScHWeRnsChweRN    sChWErN   SchweRN  SCHWErNSChwERnsCHwERN    
  sChWErn  ScHWeRn	schweRn 	  sCHWErN	    schWeRn    scHWeRN 
   SchWeRN	scHWErn SchwErn       scHWErn	    ScHweRN	  sChwern      
scHWerN        scHWeRn		 scHWerN	ScHwerN       SChWeRN scHWeRn  
	SchwERNschwERn	      SCHwern  sCHWErN	 SCHWErN	   sChWeRn 

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