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

[chromatic]

Well, that would address /one/ of my concerns, that is it would not just die on an unblessed reference. But it doesnt address the other issues I mentioned.

Why not?

my $regexp = qr/Some Regex/;
warn "It's regexpable!" if $regexp->DOES( 'REGEX' );

my $subref = sub { ... };
warn "It's invokable!\n" if $subref->DOES( 'CODE' );

my $overloaded = Way::OverLoaded->new();
warn "It's indexable/keyable/invokable\n" if $overloaded->DOES( 'ARRAY
+' )
                                          && $overloaded->DOES( 'HASH'
+ )
                                          && $overloaded->DOES( 'CODE'
+ );

Those may not be the best role names, but I hope the idea is clear.

[demerphq]

The regex example just doesnt work. (Did you try it?) It wont work because UNIVERSAL::isa() doesnt know about "regexness", yes you can make sure that your qr// isa Regexp, but thats not a necessary condition to using a blessed qr// construct. Regexness is defined by whether the reference has regexp magic. Its yet another type-like attribute that is orthagonal to the rest. This is why i proposed the syntax I did, 'qr//' will never be a valid class name in perl, so its a perfect way to ask if something truely has a regexp magic.

The other examples arent that useful because they fall into the same trap that UNIVERSAL::isa() did, that is confusing class names and types. Without recourse to a secondary routine like blessed() you can't distinguish an unblessed true hash reference from a blessed array reference that wants to mess up your code. AND to make things worse being a member of any of these classes does not actually say if your object supports a given dereferencing operation.

In other words there is a clear difference between asking "does an object do what the class ARRAY does" and "can I dereference an object as an array". They are orthagonal concepts in perl that have no necessary relationship with each other, despite the fact that UNIVERSAL::isa() decided to merge them. (Arguably a design error much akin to ref() returning classnames on blessed objects).

And again thats why I suggested the overload::Method like syntax for this, it separates out dereferencability from class membership in a way that lets you ask both questions, in a convenient and unambiguous way, so that people can do what they need to do without using a secondary routine. For instance all of your examples here really need to say

use Scalar::Util; 
if (blessed($overloaded) && $overloaded->DOES( ... )) { ... }

If that guard clause is needed (and it is) then the utility of UNIVERSAL::DOES drops considerably, if not more given that it currently is just a simple wrapper around UNIVERSAL::isa(). Wheras recoded to behave as I've outlined here and it would be able to replace almost every use of reftype(), blessed() and UNIVERSAL::isa() in non-serialisation code out there.

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.

Also, earlier in this thread you made a comment about ignoring various quirks of Perls design and pretending that we are working with something cleaner. In my opinion that approach doesnt lead to useful advances in the state of the art and in fact just leads to oversights. Like the fact that UNIVERSAL::DOES is currently useless unless complemented by the use of Scalar::Util::blessed(), which is hardly an advance over UNIVERSAL::isa(), more like a step backwards if anything. If you can swallow the fact that Perl isnt as clean as you want we can get a truely useful UNIVERSAL::DOES that scratches what I know to be some of your itches, and scratch the itches I have too, and finally introduce a type introspection tool that doesnt need helper routines from disparate modules spread throughout the core. Now that would be progress.

[chromatic]

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.

[demerphq]

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,