El 8 sept 2019, a las 17:55, ducasse <stepharo@netcourrier.com> escribió:
On 8 Sep 2019, at 10:15, tesonep@gmail.com <mailto:tesonep@gmail.com> wrote:
Hi, I really like the idea of returning a node object for the initialization. From seeing the class definition, I think we should assume that:
- the receiver of the slot instantiation message is a Slot. - the parameters to the slot instatiation message are literals or literal-only expressions.
Do you think that these assumptions / constraints are cool / enough?
I had the same :) Now I wondered if allowing a block would make sense.
If you need behaviour specific for your domain, you can always create a subclass of slot and redefine read: and write:, ++ you donât need a block :D ++ it makes it super explicit youâre doing some magic
But it automatically raises the evaluation environment so I would prefer not.
Cheers.
On Sun, 8 Sep 2019, 09:41 ducasse, <stepharo@netcourrier.com <mailto:stepharo@netcourrier.com>> wrote: Hi
Iâm fixing the class definition parser and I have a question.
Iâm stabilizing the API of CDSlotNode
1 âfirst' => LazyClassVariable default: 5. 2 âsecond' => InstanceVariableSlot. 3 âinstVar3â
Here is a proposal
slotdefinition(3) name ? variable name >>> âinstVar3'
slotDefinition(2) slotClass? >>> InstanceVariableSlot
slotDefinition(1) initializationMessage >>> 'default: 5â or better >>> Node(default: 5) if it exist
S.