At 09:16 PM 8/9/00 +0000, David L. Nicol wrote:
>Nathan Torkington wrote:
> >
> > Dan Sugalski writes:
> > > Which sort of argues for localtime in a numeric scalar context to return
> > > epoch seconds, in a string scalar context to return a time string,
> and in a
> > > plain scalar context a hashref. (or mini-object, or tied thingamabob, or
> > > whatever) Of course, we're trying to kill $! which does that, which is a
> > > counter-argument...
> >
> > I'm nervous about these different contexts. I thought scalar vs list
> > was confusion enough. Now we're talking about overloading even
> > further? We need to think VERY long and VERY hard about this before
> > thinking it's a good thing.
> >
> > Nat
>
>
>We could stop insisting on these finitely enumerated and nonextendable
>"contexts" and start allowing overloading assignment, like so:
>
>The assignment operator is selected from the Rvalue's methods, therefore
>the Rvalue gets to examine the type of the Lvalue and decide what to give it.
Both the l and rvalues will need to participate somehow, if for no other
reason as to make sure that:
@foo = @bar;
doesn't bother with the list flattening/unflattening trick. I'm not sure
that giving the rvalue unconditional control's a good idea.
>In this scheme, "time" could by default return an integer, except if the
>Rvalue has a defined time-override method, in which case it is used instead.
Gack. The problem there is then you need to worry about time-return,
stat-return, shm-return, foo-return, bar-return... Icky. I think perhaps
Plan B would be better. (And no, I have no plan B at the moment)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
