: At 06:20 PM 4/20/2001 -0300, Filipe Brandenburger wrote:
: >Please tell me if there really is an use for overloading && and || that
: >would not be better done with source filtering, then I will (maybe)
: >reconsider my opinion.
I think it's a category error to talk about overloading && and ||,
which are not really operators so much as they are control flow
constructs. You really have to talk about overloading boolean context
in general.
Dan Sugalski writes:
: @foo = @bar && @baz;
That will probably be written with a colon, something like:
@foo := @bar && @baz;
and do everything in scalar context. Think of it as doing something
roughly equivalent to a Perl 5-like
*foo = \@bar && \@baz;
As to what
@foo = @foo && @bar;
(no colon) will mean in Perl 6, I confess I'm not yet sure. Perhaps
the && will force scalar context on its arguments, then the assignment
to @foo will have to figure out whether to flatten the return array
reference, perhaps based on some hint supplied by the fact that &&
was itself in list context. (Much as any lazy list might come in as
a reference that is marked to be expanded when read out.)
But in general, yes, we do need to be careful to distinguish the vtable
of the variable from the vtable of the value. Consider:
my Cat %chases :<constant shared tied(Catalog)> = { ... };
This is much like a method:
my Cat &chases (Dog $spot) :<lvalue method> = { ... };
In either case, Cat is the type of the return value, and really has
little to do with the implementation of the function (or hash) itself.
$spot.chases is a Dog method, not a Cat method. In the same way,
%chases is a Catalog method, not a Cat method.
Larry
