--- Begin Message ---
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 <[email protected]> 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 <[email protected]>
>> wrote:
>>
>>
>>> On 24 Nov 2017, at 00:21, Clément Bera <[email protected]> wrote:
>>>
>>>
>>>
>>> On Fri, Nov 24, 2017 at 12:00 AM, Stephane Ducasse
>>> <[email protected]> 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
--- End Message ---
