[Vm-dev] Having a specific class for temp vectors

Clément Bera bera.clement at gmail.com
Sat Nov 21 17:04:41 UTC 2015


2015-11-21 17:29 GMT+01:00 Levente Uzonyi <leves at elte.hu>:

>
> I checked how the implementation actually works, and I came to the
> conclusion that using a separate class might be a good idea, because
> there's no easy way to tell if an Array returned by #tempAt: is a temp
> vector with some temporaries or just a regular array in a temporary
> variable. This means that returning the wrapped objects would probably
> require a lot more changes.
>
> I'd still refrain from the additional changes which would introduce some
> overhead in the methods you listed. Why?
> For #become:, I understand the reason why you'd want it to add the check,
> but there are so many other cases to handle (e.g.: "true become: false") if
> you want to make #become: safer.
> For immutability, I don't see the reason for the restriction. What if I,
> as the programmer, want to do a little hack, and overwrite the value of a
> temporary variable of a given block. That should work IMHO. So making the
> array immutable is fine, making the user unable to make it mutable is not.


Well the problem is that if you make a temp vector immutable, remote temp
accessing use unchecked temp vector access that mutate the temp vector even
if it is immutable. So basically at:put: would fail on the temp vector but
access though the remote temp bytecode would still mutate it.


>
>
> Levente
>
>
> On Sat, 21 Nov 2015, Levente Uzonyi wrote:
>
>
>> Wouldn't it be a better solution to change #tempAt: to return the wrapped
>> object instead of the temp vector?
>>
>> Levente
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20151121/2c646a02/attachment.htm


More information about the Vm-dev mailing list