> El 8 sept 2019, a las 17:59, ducasse <steph...@netcourrier.com> escribió: > > > >> On 8 Sep 2019, at 09:17, ducasse <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 > > Right now I return a symbol instead of the class but I could return a class. > Now I would like to avoid to blindly think that we have a single namespace. > So returning a class implies to be sure that the definition is parsed in the > same environment > than the class it refers and to me this is a constraint I do not like. > So I will return a symbol. > Let me know what you think.
maybe #slotClassName instead of #slotClass? I’m not against the symbol... > >> slotDefinition(1) initializationMessage >> >>> 'default: 5’ >> or better >> >>> Node(default: 5) if it exist > > Now I do not know what to do: because I can create a message with an empty > receiver. > Because Two simple solutions that come to my mind 1) ‘instVar3’ generates a CDSlotNode with a default #slotClassName = #InstanceVariableSlot (I like this solution the less because it hardcodes in the parser knowledge about the runtime) 2) we have two different nodes (becase they have different syntax) CDSlotNode and CDDefaultSlotNode and DefaultSlotNode does not have a class name and should be visited differently. >> >> S.
