Hi clement you should discuss with marcus. I had the impression that he was thinking that slot should disappear.
Stef On Wed, Nov 22, 2017 at 2:35 PM, Clément Bera <[email protected]> wrote: > 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 #temp > > So 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: > > What do you think ? > > Best, > > > -- > Clément Béra > Pharo consortium engineer > https://clementbera.wordpress.com/ > Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
