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 sChWeRnThread Previous | Thread Next