> El 8 sept 2019, a las 17:55, ducasse <steph...@netcourrier.com> escribió: > > > >> On 8 Sep 2019, at 10:15, teso...@gmail.com <mailto:teso...@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, <steph...@netcourrier.com >> <mailto:steph...@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. >> >> >> >
