> >However, making it a UNIVERSAL method also dictates that this:
> >
> > my SomeType @a :someattr;
> >
> >*must* be either:
> >
> > 1. a builtin type
> > 2. tied
> >
> >To get its attributes back out. I'm not sure this is going to always be
> >true.
>
> It must be my sinuses. I don't get that at all. Firstly, @a can't be tied
> before that statement since you only just declared it; the tie would have
> to follow. Secondly, if the declaration declares @a as belonging to class
> SomeType, then unless SomeType.pm is perverse enough to override the
> attributes() method, why won't @a->attributes go through to
> UNIVERSAL? Whether or not SomeType is builtin?
>
> Or are we talking apples and oranges and the above declaration is intended
> to declare that any *member* of @a is of SomeType, never mind the array
> itself?
Yes, I think that second sentence hits the point. Currently, there's
ambiguity as to whether or not a type declaration on an array/hash means
to be applied element-wise or whole-component-wise.
If it's the latter, then there's no problem. And I suspect that's how
we'd want it to play out. I was just raising the concern that with the
current ambiguous non-definition of types (it's "conceptware" at this
point :), it could mean either one.
I pushed a lot of these issues in RFC 319 and 337, which would let you
say something like:
my Pet @pets :mean; # integrated implicit tie
@pets->attributes('mean') # "true", like 'can'
Although, if we got verb tenses right I'd really like that to be:
$spot->has('meanness');
:-)
-Nate
