--- David Storrs <[EMAIL PROTECTED]> wrote:
> On Tue, Jul 08, 2003 at 05:52:04PM -0700, Austin Hastings wrote:
> >
> > --- Jonadab the Unsightly One <[EMAIL PROTECTED]> wrote:
> > > Am I now thinking clearly?
> > >
> > I don't think so.
> >
> > If you've created two separate arrays that happen to start with
> related
> > values, then the changes to the first won't affect the second.
> >
> > If splice overwrites the values instead of dropping and then
> replacing
> > them, it's going to produce some strange behavior.
>
> What kind of strange behavior? Can you give an example?
Sure:
<perlfunc>
splice ...
Removes the elements designated by OFFSET and LENGTH from an array, and
replaces them with the elements of LIST, if any.
</perlfunc>
You have an array of Things. @a[0..2]
You use splice to replace 2 and add 2 more: @a.splice 1, 1, $x, $y, $z;
Now, what happened to @a[1] (the original one)?
According to "what I think I know about perl", it was removed from the
list.
Which means it may (or may not) be GCed at some point, but it's
potentially still a viable object.
OTOH, if splice is going to try to overwrite the values, then the
C<typeof $x> and C<$typeof @a[1]> should match, because there's going
to be a body-swap. And that means (for advanced types) that splice may
have to call the assignment operator, close filehandles, etc.
I don't think we want the second one.
>
> > I think that for example:
> >
> > my @a is Array of int;
> > my $r_slice is Array of int;
> >
> > # ... as before ...
> >
> > should behave as expected, and "expected" in this case means
> > copy-on-assign.
>
> Could you elaborate on this?
@r = @a[1,3,5];
I don't think there should be some kind of wierd magic tie. I think
that the assignment is done, and any subsequent change to @a should be
invisible to @r.
$r_slice = @a[1,3,5];
Ditto.
$r_slice = @a[potentially_infinite_iterator()];
Now what? Especially since @a could potentially be a (potentially
infinite) tied thing? To me, the right behavior is to copy the values
of @a on assignment. To be more specific:
my @a is Array of Num value { $^a * 2 };
my $r_slice = @a[1 .. { 2 * $^a + 1 }];
So $r_slice should return the odd members of @a, which itself contains
Num.Inf even numbers.
So what then happens if I say @a.shift?
Should $r_slice be late-bound, and suddenly one of it's members doesn't
appear? I think this is "trouble waiting to happen", since when we get
to mixed literal/generator slices (e.g., ... =
@a[1,3,11,22,generator()]) the implementation will be forced to copy
the literal part.
Instead, I think that $r_slice should get a new "composed" generator
function (a "copy" of @a's values, filtered through the "slice id") so
that subsequent shift/unshift/splice operations on @a don't affect it.
> >OTOH, if you said C<$r_slice := @a ...> then you'd be
> > binding, not copying, and the one-change-affects-both behavior is
> in
> > effect.
> >
> > =Austin
>
> You also wouldn't be using a slice, you'd be using a reference to the
> array. Or was the ellipsis supposed to indicate the slice indices?
Yeah, it was supposed to mean "all that stuff he typed above".
Essentially, what I'm getting at is that = vs. := is still meaningful
in slice context (where possible).
=Austin
