I am not aware of any special reason why it was done that way, I think it is fine to change... though all uses cases should be fixed (in amber-contrib-legacy and in Helios' inspectors, for example).
Though, the question is what to do with the instVarAt:[put:] API itself - Amber does not have indexed ivars, so it cannot be even properly implemented (well, you can use the list of ivars in class definition, maybe). I don't know if there are other users of this API in the form in which it is now.
Sean P. DeNigris wrote:
> Right now, #instVarAt:put: does what #instVarNamed:put: does in Pharo. I
> noticed this when importing data saved in Pharo via #storeOn:. Can we rename
> to match Pharo, or was this done for a reason? In Pharo, #instVarAt:put:
> takes an index, which was what I actually needed to materialize my data...
>
>
>
> -----
> Cheers,
> Sean
> --
> View this message in context:
http://forum.world.st/instVarAt-put-tp4832343.html> Sent from the Amber Smalltalk mailing l
ist archive at Nabble.com.
>
--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
[hidden email].
For more options, visit
https://groups.google.com/d/optout.
Locked
