<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Lukas Renggli wrote:<br>
<blockquote
cite="mid:67628d690803151010l4ebc9e23iefdeeaaa4ac27d1c@mail.gmail.com"
type="cite">
<blockquote type="cite">
<pre wrap=""> | array |
array := #(1 2 3 4 5) copy.
array restoreFrom: #(4 5 6) copy.
array
---> #(4 5 6 nil nil)
| array |
array := #(1 2 3) copy.
array restoreFrom: #(4 5 6 7 8) copy.
array
--> Index out of bounds exception
</pre>
</blockquote>
<pre wrap=""><!---->
This is not how the backtracking API works, #copy is not part of it.
Have a look at WABacktrackingTest:
</pre>
</blockquote>
<br>
Just a note: The "copy" above was just a VisualWorks work-around to
get around immutable literal objects. I could have said "beMutable" or
I could have created the arrays using with:with:with: etc. For the
purpose of this problem, you can ignore the copy.<br>
<blockquote
cite="mid:67628d690803151010l4ebc9e23iefdeeaaa4ac27d1c@mail.gmail.com"
type="cite">
<blockquote type="cite">
<pre wrap=""> Michael Lucas-Smith tried it in Squeak and the first example produced
#(4 5 6 4 5) and the second one produced: #(4 5 6).
</pre>
</blockquote>
<pre wrap=""><!---->
Arrays are considered to be immutable in size in Squeak.
</pre>
</blockquote>
And I think Arrays should be considered immutable in size. This
mechanism isn't designed for arbitrary become: calls and shouldn't need
to worry about that. My main concern was actually OrderedCollection.
In VW, OrderedCollection contains named and indexed instance variables
and grows using become:. Maybe not the best implementation, but that's
what's there. This mechanism would have trouble with that unless you
make a special case for OrderedCollection.<br>
<blockquote
cite="mid:67628d690803151010l4ebc9e23iefdeeaaa4ac27d1c@mail.gmail.com"
type="cite">
<blockquote type="cite">
<pre wrap=""> To do this properly, you'd first have to create a new collection of the
proper size, use a become: to change the original collection back, then
restore it to the proper values using the existing restore mechanism.
Am I out to lunch on this one or does this change need to be made?
</pre>
</blockquote>
<pre wrap=""><!---->
You need to implement #snapshotCopy and #restoreFromSnapshot: in
OrderedCollection according to your internal implementation. I guess
#snapshotCopy just returns a shallow copy (the default), while
#restoreFromSnapshot: can do a #become: of a copy of the snapshot to
the one you want to restore. Or something like that.
Lukas</pre>
</blockquote>
This sounds reasonable. The snapshotCopy method should be fine as is.
It's the restoreFromSnapshot: that would need to be implemented in
OrderedCollection.<br>
<br>
Thanks<br>
David Buck<br>
<br>
</body>
</html>