At 03:32 PM 10/2/00 -0700, Nathan Wiger wrote:
> > >There's two ways I've proposed in different RFC's. The first one
> > >utilizes a more general framework; the second one depends on C<tie>
> > >being used. A UNIVERSAL:: method wouldn't work because you've got to get
> > >attributes from arrays and hashes as well.
> >
> > 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.
>
>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. In particular, what if SomeType was like "int", and you were just
>trying to assert that each individual element was going to be SomeType?
Then the int package would Do The Right Thing, of course. :) Just because
they're provided types doesn't mean we won't be using the standard methods
on them. (Though granted we may push a lot of the twiddly details into the
main perl compile since we'll already know them--no reason to be
unnecessarily dynamic)
And even if the int/float/str/bigint/bigfloat types aren't really modules,
there's no reason the core can't fake it to look like they are...
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
