Thanks, I was looking for usages of InstanceVariableSlot.
All instance variables are InstanceVariableSlots.
But to make it less verbose, we have a way to specify these without having to put the name.
Object subclass: #Point
slots: { #x. #y }
classVariables: { }
package: 'Kernel-BasicObjects���
is the same as
Object subclass: #Point
slots: { #x => InstanceVariableSlot . #y => InstanceVariableSlot}
classVariables: { }
package: 'Kernel-BasicObjects'
If you evaluate:
Point slotNamed: #x
you see that it returns a
#x => InstanceVariableSlot
Slot instance.
(with all that: I sometime wonder if we should not get rid of the name ���Slot��� and just use the term ���Variable������ because that is what they are���)
In the case of SlotExampleMovie, #name and #year are of IntanceVariableSlot layout (this definition is correct? A slot is or has some Layout defined by the Slot class?)
No, the class has a Layout. See subclasses of AbstractLayout. This reifies the magic number that is in the ���format��� ivar of Behaviors (third ivar of all class like objects).
In addition it makes class definition *explicitly* specify the layout.
So Array in ST 80 is something like:
ArrayedCollection variableSubclass: #Array
instanceVariableNames: ''
classVariableNames: ''
package: 'Collections-Sequenceable-Base'
so the layout chosen is hidden in the class creation method (variableSubclass���), while with the reified layouts, it explicit:
ArrayedCollection subclass: #Array
layout: VariableLayout
slots: { }
classVariables: { }
package: 'Collections-Sequenceable-Base���
e.g. for CompiledMethod it makes clear that is a very special class:
CompiledCode subclass: #CompiledMethod
layout: CompiledMethodLayout
slots: { }
classVariables: { }
package: 'Kernel-Methods���
> On 6 Feb 2019, at 12:41, Denis Kudriashov <dionisiydk@gmail.com> wrote:
>
> Would be nice to have a command in browser to show users of selected slot
>
Yes!
Marcus