On 21 Nov 2015, at 17:29, Levente Uzonyi leves@elte.hu wrote:
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.
I think that a language implementation should support reasonable extensions with good reason (I do not see a good scenario for overwriting the value of a temp in a block - do you have a real example in mind) and language implementors should get space for optimisation.
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