Marcus, I agree with keeping it as Slot. The existing literature (non-Smalltalk) uses Slot in a fairly consistent manner so what would the advantage be of changing it? Reg Sent from my iPhone
On Nov 24, 2017, at 4:44 AM, Clément Bera <bera.clement@gmail.com> wrote:
In the VM primitiveSlotAt: / at:Put: mean access to any field (pointer or non pointer, sorry for the confusion Marcus earlier on) of an object. The primitive in the image can be named fieldAt:/fieldAt:put: if it makes more sense for Pharo.
#[0] slotAt: 1 => 0 #(#a) slotAt: 1 => #a 0@2 slotAt: 1 => 0 With Pharo 6 blocks: | t | t := #tmp. {[ t ] slotAt: 3 . [ t ] slotAt: 4} => { 0 "numArgs". #tmp }
Right now you can do that with instVarAt: on the contrary to what instVarAt: comment states, and this is wrong.
On Fri, Nov 24, 2017 at 10:32 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 24 Nov 2017, at 00:21, Clément Bera <bera.clement@gmail.com> wrote:
On Fri, Nov 24, 2017 at 12:00 AM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Did you talk with marcus?
I don't understand the connection between slots and this problem with primitives.
There is no connection, just the same name.
For Slots aka First Class Instance variables:
I sometimes think that Slot for the first class instance variables might not be a good name, but then, the only alternative would be âinstance variableâ, but that is not that nice either, as these Slots include virtual variables (that are computed) or variables that are combine stored in a hidden base slot (e.g. used for BooleanSlot or PropertySlot).
So for now I will keep the Slot termâ¦
Marcus
-- Clément Béra Pharo consortium engineer https://clementbera.wordpress.com/ Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq