Thomas Sandlaß skribis 2005-05-10 19:02 (+0200):
> Juerd wrote:
> > No, again, please do not make the mistake of thinking VALUES have
> > identity. VARIABLES (containers) do. A reference points to a container,
> > never to a value directly.
> I don't consider it a mistake.
That is a problem.
> So, you dany identity to "fat" values like database connections or GUI
> objects?
Objects are references to containers. Primitive values, like strings and
numbers are not objects. They can be used as objects, though.
Assignment copies. When that is a reference, the reference is copied. It
still points to the same thing. Thus, $obj2 = $obj1 DOES NOT clone, even
though $str2 = $str1 DOES clone the string.
Containers have identity. Objects are references to containers. The
identity of an object is that of the referred container, not the
container that holds the reference.
Database connections and GUI objects are objects, and as such have their
own containers, which have identities.
> > Try in perl (5) the following code:
> > my ($xx, $yy) = \($x, $y);
> Actually I still wonder how equal or different assignment
> with = of a ref produced by \ is from binding with :=.
t is because you lack understanding of the system of names,
containers and values that Perl uses. As long as you think values have
identity and containers are always implicit, you cannot understand the
difference between aliasing and referencing. Or the difference between 4
and $foo = 4, for that matter.
> The second line above e.g. should produce a ref to a list value
> (undef, undef), right?
List references do not exist (array references do, but that is entirely
besides the point). \($x, $y) in Perl 5 returns the same as (\$x, \$y).
I'm sorry I assumed you knew Perl 5, I'll try to explain my code next
time.
> Then this value shall be used to initializes the content of whatever
> the names $xx and $yy refer to. So, why don't the references not just
> vanish and we get to independent undef values stored in $xx and $yy?
Why should references "just vanish"? That's not a likely course of
action a reference will take. A reference only vanishes when something
else replaces it, or it is garbage collected.
> I.e. do you expect $x = 5 have an effect on the value of $xx?
No. $xx's value still points to the same container, the container that
$x also points to.
name : container : value
......:.............:..........
: :
$xx ----> SCALAR ----> (REF)
: : |
: +-------------+
: V :
$x ----> SCALAR ----> 5
: :
: :
Or, using the boxes metaphor, where each box is a container, and in it
is drawn its value, and names are outside of boxes
+- $xx +- $x
| |
V V
+-------------+ +---+
| reference -----> | 5 |
+-------------+ +---+
Now, if you do either $x-- or $$xx--, only the value of the container
previously holding 5 changes:
name : container : value
......:.............:..........
: :
$xx ----> SCALAR ----> (REF)
: : |
: +-------------+
: V :
$x ----> SCALAR ----> 4
: :
: :
boxes:
+- $xx +- $x
| |
V V
+-------------+ +---+
| reference -----> | 4 |
+-------------+ +---+
If $xx was an alias for $x, thus "$xx := $x" instead of "$xx = \$x", it
would be like this:
name : container : value
......:.............:..........
: :
$xx --------+ :
: | :
: V :
: SCALAR ----> 123
: ^ :
: | :
$x --------+ :
: :
: :
(I moved $x to another line to show that $x and $xx are both equal in
"rank": none is the "real" name, they're both real.)
boxes:
+- $x +- $xx
| |
V V
+---------+
| 123 |
+---------+
> > Declaration and := bind names to containers.
> I disagree.
Do you disagree that they do, or that they should?
Because they do do.
> Names are a compile time concept
Well, not strictly.
> and access to the namepace level is restricted after compilation.
Not at all, in Perl.
> Some languages like C++ and Java actually compile the namespace almost
> completely away.
Perl is not "some languages", and certainly not C++ or Java.
> So Declaration is mostly a way to talk to the compiler while := is a
> runtime operator.
Perl knows many runtimes, of which some are often called compile time.
> > A reference points to a container.
> Well, can we agree that a reference is a means to retrieve a value?
No. It's a means of pointing to a container. To get that container's
*value*, you need to dereference. Dereferencing can happen implicitly,
in Perl 6.
> >The reference isn't to $y's container's value, but to the container.
> >Regardless of its value. It is also not to the name $y.
>
> I don't see much use in pointing to a container because the interest
> is in the value unless to want to go in an explicit pointer arithmetic
> scheme like C++.
First of all, even if you do not see much use in it, stop ignoring the
simple fact that this is how Perl has always been.
If you're trying to change the way Perl handles these things, propose
the change. Don't continually mess up discussions in which current
semantics are assumed.
> Does \$v + 1 mean something different than $v + 1?
Certainly in Perl 5. In Perl 6, $v there may auto-dereference, which
effectively would mean they're the same. I am very strongly against
autodereferencing of scalars, though.
> $rr = \$y; # read ref (or view)
Reference. ($r --> [ reference-]-> [ $y's container ])
> $wr := $x; # write ref
Not a reference. ($wr --> [ $x's container ] <-- $x)
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
