Hi.Just to notice: it is here long time (I checked Pharo 1 and current Squeak).
2017-11-22 14:35 GMT+01:00 Cl��ment Bera <bera.clement@gmail.com>:Hi All,It seems Pharo is lacking the slotAt: / slotAt:put: primitive and that the instVarAt: / instVarAt:put: primitive is not doing what it says it does. When I look at Object>>#instVarAt: I see:"[...]Answer a fixed variable in an object. The numbering of the variables
corresponds to the named instance variables, followed by the indexed instance
variables. Fail if the index is not an Integer or is not the index of a fixed variable[...]"Now in Pharo 7 when one does:��#(iv1) instVarAt: 1, one gets��#iv1.So the comment is wrong.The reason for this is that instVarAt: / instVarAt:put: should be primitive 73/74, while they are in Pharo 173/174 (primitive slotAt:/slotAt:put:). The slot primitive access pointer slots of objects, whichever inst var or variable fields. A good example would be:| t |t := #temp.[ t ] instVarAt: 4, one gets #tempSo I have two solutions for this problem:1) We change the instVarAt: / instVarAt:put: primitives comments to match the slotAt: / slotAt:put: behavior, and in Pharo instVarAt: / instVarAt:put: means in factslotAt: / slotAt:put: .2) We change the instVarAt: / instVarAt:put: primitives to primitive 73 and 74, we introduce slotAt: / slotAt:put: with primitive 173/174 and we ask everyone to fix their code relying on instVarAt: / instVarAt:put: acting as slotAt: / slotAt:put:I prefer explicit behaviour. These methods have clear intention in names: inst var accessing. It should be error when given index is out of #instSize range.��For new methods I would not use slot based naming because slots in Pharo is already something more then just object fields.��Maybe #fieldAt:, #fieldAt:put: would be good? And also #fieldSize for consistency��
��What do you think ?Best,--