Ariel Scolnicov wrote:
> John Porter <[EMAIL PROTECTED]> writes:
> >     foo = bar;
> > 
> > foo could be just about anything: a string, a hashref, some other
> > blessed ref (with op"=" possibly overloaded!), or even an lvalue sub.
> > Do you know?  Should you care?
> 
> I don't know, but I think I should care.  Suppose C<bar> holds a
> reference to a list.  What does C<foo = bar> do?  Does it make C<foo>
> another reference to the same list, or does it make C<foo> a reference 
> to a new copy of the same list, or does it make C<foo> a copy of the
> same list?

My point is that knowing the answer to these questions *already*
depends on looking up what foo (or $foo, or @foo) is, and how it's
implemented.   By using a simple traditional scalar, $foo, you've
simply selected one of many possible classes for the object, in which
case you know what the assignment does.  Ditto with @foo.  And if you're
just looking at the context of the assignment, you can't know whether
$foo (or @foo) is tied, and if it is, what the "assignment" really does.

-- 
John Porter

Reply via email to