Re: set myList to myList & ...(Digest, Vol 2, Issue 493)
Re: set myList to myList & ...(Digest, Vol 2, Issue 493)
- Subject: Re: set myList to myList & ...(Digest, Vol 2, Issue 493)
- From: has <email@hidden>
- Date: Wed, 27 Jul 2005 19:51:56 +0100
Jonathan Levi MD wrote:
>With all respect to has and Paul, and with no wish to be tendentious:
>has quotes a previous writer (himself, possibly: I don't know):
> >>>...you've misread the problem. This has nothing to do with set vs
> >>>copy. It's about the concatenation operator not returning a new
> >>>object in certain situations. Example: [...]
>
>However, in the example that followed and is reproduced below, the comment "Wrong!" by (a second) previous writer has to do to with value-vs-reference, not concatenation:
>
> >>set l to {1} (1)
> >>set a to l & {} (2)
> >>set b to {} & l (3)
> >> (4)
> >>set l's item 1 to 2 (5)
> >>log a --> {1} (6)
> >>log b --> {2} -- Wrong! Should be {1} (7)
(All three quotes are mine.)
Yeesh... Okay, one last time: the issue has bugger all to do with assignment. I know how assignment works [1] and I've a pretty shrewd notion of how concatenation is *supposed* to work, so when I say "the problem is in the concatenation operator" I do mean "the problem is in the concatenation operator", and not "I just got off the boat yesterday".
>The second writer doesn't object that a concatenated value is missing somewhere: He objects that the value shown by "log b" in line (7) is the wrong value,
The bug occurs on line 3. Mutating the content of the object bound to 'l' (line 5) and viewing the value of 'b' (line 7) shows that the object bound to 'l' in line 1 has ended up bound to 'b' in line 3. And the only way that can happen is if the concatenation operation in line 3 has returned one of its operands *as-is* instead of *joining* the two operands to create a *new object*. One can hypothesise on the reason for this odd behaviour - most likely it's an internal performance optimisation gone awry - but that's by-the-by. The point is that it's contrary to both common sense and official documentation would indicate, inconsistent with the operator's other behaviour and introduces a subtle but unpleasant gotcha into users' code.
BTW, here's the same example in a non brain-damaged language for comparison:
#!/usr/bin/python
l = [1]
a = l + []
b = [] + l
l[0] = 2
print a # --> [1]
print b # --> [1]
It's a bug, somebody file a report before I run outta possible ways to rephrase it, and let's move on already.
has
[1] It's by-value, where that value is a reference to a heap-allocated object. Just to be precise.
--
http://freespace.virgin.net/hamish.sanderson/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden