Front page | perl.perl5.porters |
Postings from November 2003
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
it.
There's no point putting it in the core. Its too dangerous.
* likely to cause *more* UNIVERSAL.pm problems by expanding the
methods in UNIVERSAL.pm, no matter how hard they try to be
transparent
* 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 schwern@pobox.com http://www.pobox.com/~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