>> >> 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?
Yes I will rename typeName > 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) Yes I did this. > 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. Yes. I was wondering what would be initializationMessage part of a normal slot. And may be having these two can solve the problem. I do not like to put a nil or #() in the initializeMessage (and I was thinking that I would need a NullMessage but this is not nice. So I’m thinking that having two different nodes may be good now I do not know what to do for the initializeMessage (if it would be an action I would do nothing) > >>> >>> S.
