On Fri, 3 Jan 2003, Dave Whipp wrote:
> John Williams wrote:
>
> > Do they? One is obviously an array, and one is obviously a scalar.
> > You may get an error (cannot alias an array as a scalar) or $b get aliased
> > to the array-in-scalar-context (a reference).
>
> This is one of those "how we think about the fundamentals" things. I am
> taking the viewpoint that "everything is in object".
How you or I think about the fundamentals is a moot point, really.
Objects are not covered until apocalypse 20-something, so the main thing
we have to go on is Larry's statement to the effect that things will
behave like objects if you treat them like objects.
> One of the issues I hoped to provike discussion of is the
> difference between
>
> $b = @a;
> and
> $c := @a;
>
> The former obviously creates a reference to the array; but does the
> latter?
That is a good question. Someone wiser that me will have to interpret the
true meaning of $c := @a;.
> An ArrayRef is an object that provides indirection to an array
> object. But for $c, I have requested a binding, not an assignment. $c
> should hold, literally, the same object as @a. If an ArrayRef is a new
> object, then we shouldn't create this new object as part of a binding
> operation.
Saying an Arrayef is a different object from an Array may be taking the
analogy a bit too far. They are different things, yes, but since perl6
references dereference automatically, calling an method on an ArrayRef
will be the same as calling a method on the Array it references.
> If only objects have types then yes, you'd override the .num method. But
> that sidesteps the issue: what if a *variable* has its own behaviour.
Well, I suspect that would be a bad idea. One of the really annoying
things about most OO languages is that if I call my Geo Prizm a
"Vehicle", it suddenly forgets that it is a Geo Prizm. So
$ParkingLot.Vehicle[38].door.open() would fail because not
all Vehicles (motorcycles) have doors. I really hope that a
weakly-typed, OO language will free me from type-casting hell.
If variables get to have their own behavior, then you have accomplished
the same thing in a different way. We will have to typecast our
cars/objects every time we go the the parking lot/collection, because we
want them to stop acting like generic vehicles/superclasses.
> my Foo $a = ...;
> my Bar $b := $a;
>
> Assuming that Foo and Bar are both compatible with the referenced
> object,
To be compatible, they have to be the class of the object or a superclass
of the object, right? ("Have the interface of" is like saying it's a
superclass for languages that don't have multiple inheritance.)
> do both $a and $b behave identically? Or can the variable's type
> influence the behavior of that variable
...
> This might seem like a silly thing to want to do;
Yes.
> but it seems to me
> that there are often cases where we want different behaviors in
> different contexts.
There may be cases, yes. Making it the default case is a probably a
really bad idea. Hopefully my example above illustrates why.
If you are in that case, I imagine you can just do $a.Bar::xxx() or
$a.Foo::xxx() to get what you want.
~ John Williams
