in reply to Re^6: I don't understand UNIVERSAL::DOES()
in thread I don't understand UNIVERSAL::DOES()

I really want to see a unification of all the various type-like detection code into one routine and it seems to me that DOES is the best candidate for the job.

Me too.

However, tying that to "What kind of SV is this?" is a mistake.

Yes, of course people can write bad DOES() methods. Yes, of course people can bless references into classes named after builtins and get the wrong answers. Yet people can also neglect to escape SQL from user input, build their own templating systems, build their own query parsers, forget to check the results of system commands, factor their code improperly, write ten-thousand line functions, use only global variables, and use symbolic references.

I don't really care if bad programmers can abuse a feature if that feature makes it easier for decent and good programmers to do their jobs well.

As I said, perhaps class names are the wrong role names for asking "does this entity support indexed access" or "does this entity support keyed access". That's fine.

But please give me a little credit as the Perl 6 designer who's thought about this for a few years now--unifying types and roles is a good thing. Querying objects and types about their capabilities instead of their peculiar and accidental structural lineage is a very good thing. Unifying that behind an interface that allows encapsulation of the how and merely asks the question "do you?" is the right thing.

I could never have convinced Larry and Damian, especially, if this were not so.

Replies are listed 'Best First'.
Re^8: I don't understand UNIVERSAL::DOES()
by demerphq (Chancellor) on Mar 11, 2007 at 09:14 UTC

    However, tying that to "What kind of SV is this?" is a mistake

    Well I didnt suggest "what type of SV is this" I suggested, "what type of SV does the reference point to". And please explain why its a mistake. It doesnt seem a mistake to me. It seems like a proper unification of an aspect of roles that the current DOES does not address. There are three ways to tell if you can dereference a var in a particular way. You can just try it (potentially dangerous), you can check its reftype(), but if the reftype is wrong you need to check overload::Method(). This functionality should be part of DOES in my opinion. If you disagree please explain why. Im interested to understand.

    perhaps class names are the wrong role names for asking "does this entity support indexed access" or "does this entity support keyed access". That's fine.

    Ok good. I'm glad we agree on that. I think i have provided enough examples to show that using class names for this is just going to cause problems.

    But please give me a little credit as the Perl 6 designer who's thought about this for a few years now--unifying types and roles is a good thing. Querying objects and types about their capabilities instead of their peculiar and accidental structural lineage is a very good thing. Unifying that behind an interface that allows encapsulation of the how and merely asks the question "do you?" is the right thing.

    I dont think I've not given you credit. I think the idea of DOES is a good one (and ive said that elsewhere), and I agree with everything you have listed in this paragraph as being a good thing. But the current implementation leaves a lot to be desired, and will in my opinion not be widely used because it has serious deficiencies in its behaviour: the requirement that virtually any nontrivial usage of the ->DOES method be guarded by a blessed() call is a serious impediment, as is DOES not really providing a means to check if a ref can fulfil the role of a particular type of reference. Hence the code I posted elsewhere, and the patch I am preparing for p5p.

    Also, please lets avoid arguments by personal authority. We both have experience relevent to this discussion so lets just stick to the facts and to logical arguments about what the best behaviour for UNIVERSAL::DOES in Perl 5 should be. If that has to be different than how it will work in Perl 6 thats fine, as Perl 6 is /supposed/ to have a cleaner design than Perl 5 and should NOT have the various inconsistancies that Perl 5 does. Which means that for it to be properly useful in Perl 5 means that its likely to have to be able to do things that arent necessary in Perl 6.

    Anyway, I've posted a working patch to p5p that IMO resolves almost all of this stuff in a nice elegant and powerful way. If you have any criticisms of that code or the intentions it implements please post them.

    Cheers,

    ---
    $world=~s/war/peace/g