Re^5: I don't understand UNIVERSAL::DOES()

UNIVERSAL::DOES() seems like the perfect place to roll them all together into something sensible.

Do you really expect us to say UNIVERSAL::DOES everwhere?

Do you plan to allow the export of DOES despite the many places where UNIVERSAL claims it's a mistake to have import at all?

What if there's a package wants to use the DOES function *and* override DOES?

Wouldn't it be better if your function was called does. If the argument is a class or an object, it would call the DOES method to permit overrides and roles.

Comment on Re^5: I don't understand UNIVERSAL::DOES() Select or Download Code

Replies are listed 'Best First'.
Re^6: I don't understand UNIVERSAL::DOES() (import) by tye (Sage) on Mar 09, 2007 at 21:27 UTC
`*isa= \&UNIVERSAL::isa;` [download] works great for me. I don't even have to "use UNIVERSAL" for this. There being no UNIVERSAL->import() makes some sense to me, but, as noted in Universally unimportant and overused, UNIVERSAL->import() appears to exist (and causes problems). Defining a special UNIVERSAL::isa() that can detect when it has been misused would be an acceptable compromise to me. - tye	[reply] [d/l]
Re^7: I don't understand UNIVERSAL::DOES() (import) by ikegami (Patriarch) on Mar 12, 2007 at 08:24 UTC
The last paragraph was the most important, and it wasn't addressed. My fault, I didn't explain myself. Consider `{ package Foo; sub DOES { my ($self, $role) = @_; return 1 if ...; return $self->SUPER::DOES($role); } } Foo->DOES(...); # Line "A" UNIVERSAL::DOES('Foo', ...); # Line "B"` [download] Unless `DOES` does something non-intuitive, line "A" results in an infinite loop. Unless `DOES` does something non-intuitive, line "B" doesn't call the overridden `DOES`. Do we really want `DOES` to be that special? Having a function `does` (which calls `DOES` when appropriate) would avoid all this complexity.	[reply] [d/l] [select]