Abhijit Mahabal writes:
> Traits can be mean, but roles are "guarenteed"(=forced?) to play nice. But
> suppose I have a role that wants to play nicer, by ensuring that
> incorporating it in some class actually makes sense.
>
> For example, it may want to ensure that the class has $.foo. (*)
Let me start by pointing out a bit of abstraction sacreligion here, and
responding to your second question.
Neither a class nor an object can have $.foo. They have .foo, the
accessor, and only the methods have $.foo. I don't believe roles can
see the $.foo, so they also have to use .foo.
But as far as I can tell, this has little to do with the main point of
your question.
> I have a few questions:
>
> 1: Can this be achieved by a CHECK {} block in the role, that gets run
> just before the class composition is over? Or should it be spelled
> differently, CHECK {} being the last thing that run before "run-time"?
I'd say something like that. Perhaps it's a COMPOSE submethod, that
ironically doesn't get composed, because it's special that way. I don't
like that much, because it breaks the generality of composition.
Perhaps just:
multi sub does (::class, MyRole $role) {...}
Which would be run instead of the default does, but you could easily
call the default does at the top of that and then do some checking at
the bottom.
Luke
> 2: What is the syntax for checking that a class has a variable? In this
> case the class does not even really exist when we want to check.
This is somewhat bogus, as I pointed out above, but if you're feeling
really naughty, you can do it:
$obj.HAS.exists('$.foo');
Or:
SomeClass.HAS.exists('$.foo');
> 3: If arbitrary things can go into such a CHECK{} block, then the
> following two may not mean the same:
> does A does B;
> does B does A;
> Are roles I<expected> to play nice, or I<forced> to play nice?
Perl doesn't force anything, but you can consider it a strong
expectation.
Luke
