At 03:32 PM 10/2/00 -0700, Nathan Wiger wrote:
> > Maybe I'm just being dense, but why shouldn't arrays and hashes inherit
> > attributes from UNIVERSAL? tie()ing an array is really just like being
> > able to call object methods on it distinct from its members, no? So arrays
> > and hashes could be objects too. Hmm, am I saying that I should be able to
> > write @array->method()?
>
>I think under tie this is *exactly* what we should be aiming for. I
>think this is awesome.
RFC 82 would probably prefer that this have a component-wise interpretation :-)
>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?
> In particular, what if SomeType was like "int", and you were just
>trying to assert that each individual element was going to be SomeType?
>
>If these problems were resolved, then I must admit to having a perverse
>softspot for being able to say:
>
> my packed @bits :long;
> %attrs = @bits->attributes;
>
>I dunno...I like the way that looks for some reason... ;-)
Me too.
--
Peter Scott
Pacific Systems Design Technologies
