[Pharo-dev] Problem with primitive instVarAt: / instVarAt:put:, what should we do ?

Stephane Ducasse stepharo.self at gmail.com
Wed Nov 22 15:05:34 EST 2017


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 <bera.clement at gmail.com> 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




More information about the Pharo-dev mailing list