> 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.
