Hi, I'm not too deep in the CDSlotNode and related - but I wonder why we need the specific #=> selector and slotName => Definition mapping form in the definition at all. What are the benefits of the additional "=>" style ? To me it looks not very natural to write: #id => InstanceVariable. or other specific forms. The custom subclasses of class "Slot" are already inheriting the "name" iVar for the slotName. So using the additional slotName in the definition is - disrupting the slot name from other arguments - redundant if the slot creation should have the name as well Why not use just the plain slot object by creating it directly with a class message? We can just use custom class side instantiation methods for the slots including the name like #named: #named:type: #named:type:default: ... or other. I mean #=> dispatches to #named: on the slot anyway. If we define the class / slot objects like this: Object subclass: #MyTask slots: { BOInstanceVariableSlot named: #'id'. #anotherIVar. BOTypedSlot named: #'description' type: String. BOAttributeSlot named: #'isDone' type: Boolean default: true. BOAttributeSlot named: #'created' type: Date default: [ Date today ] } classVariables: { } package: 'CustomSlots-Definitions-Examples' is more natural than the => forms where the name is just disrupted from the other arguments. The attached file out from a Pharo 8 example demonstrates this. Just file it in and have a look at class MyTask or inspect "MyTask new created" or "MyTask new created: 2" to see that the implemented simple slot typing and defaults are working. Then look at the definition of #MyTask class, which looks like written above. It could be made even more readable using Object subclass: #MyTaskEvenEasier slots: { BOAttributeSlot named: #'id'. BOAttributeSlot named: #'anotherIVar'. BOAttributeSlot named: #'description' type: String. BOAttributeSlot named: #'isDone' type: Boolean default: true. BOAttributeSlot named: #'created' type: Date default: [ Date today ] } classVariables: { } package: 'CustomSlots-Definitions-Examples' only. The benefits without the => indirection are: - a simple, compact and easy readable class definition even when slots are used - slot definitions are regular messages to the slot class - simply evaluate or inspect the full slot class side message - we keep the possibility to mix slots with other instance variables (here #anotherIVar in the example by using the symbol) - we keep the possibility to evaluate the full slots definition and check the array of their definition - we unify the definition with the "MyClass slots" message - as both are just return the array of slot objects - we do not rely on an additional specific definition API one has to remember So where is the real value in the often used additional indirection of the => message in slot definitions? Thanks T.