I will have a look, but I feel that we should first get the Composed Slots into the image as they will change everything again.
Yes - would like to see them in as quickly as possible - but I fear they need more work from your side which is time and prio related as always. ComposedSlots can make things easier and allow to better control the different variations. Compositions will change how things can be composed together. But for the definition I guess we still have to decide for either - either for the "=>" approach - the plain objects approach For compositions the => syntax would allow to just write the class name if there are no parameters for the slot: { âsomeIVar' => InstanceVariableSlot + LazySlot } But using the "just objects" approach one could would make it look like: { (InstanceVariableSlot named: 'someIVar') + LazySlot new } When "+" is implemented also on instance side for composing one could even have: { (InstanceVariableSlot named: 'someIVar') + LazySlot } or { LazySlot + (InstanceVariableSlot named: 'someIVar') } to stay symmetric. It would also allow for: { ComposableSlot for: 'someIVar' using: LazySlot } "assuming that an InstanceVariableSlot is always in or { ComposableSlot for: 'someIVar' with: LazySlot new } "if one uses an existing slot instance" Anyhow - we can only experiment when https://github.com/MarcusDenker/SlotComposition moves on and becomes part of the image... Bye T.