Hi. Another option is to not expose slot class names at all and use messages instead:
- #first slot lazy default: 5 - #second slot boolean - #instVar3 slot weak lazy - #typedVar slot type: Integer; lazy #slot here will return SlotDefinition. And following messages will configure it or produce new instances. I think it is more simple approach than having "binary message algebra" for slots composition. Implementation of slots in that case will force developers to extend the slot definition API and therefore the parser. пн, 9 сент. 2019 г. в 18:21, ducasse <[email protected]>: > I would prefer that we discuss also because we need to have a design that > suits us. > I do not think Pharo will benefit to have a complex class definition. > > Stef > > > On 9 Sep 2019, at 17:20, Marcus Denker <[email protected]> wrote: > > > > > > > >> On 9 Sep 2019, at 17:00, ducasse <[email protected]> wrote: > >> > >> Marcus to me the point is that we should not rush this kind of things. > >> What we should think is > >> - freeze a syntax - I like the idea of guille to make sure that we > cannot have any message in the slot > >> - take the time to discuss the design, do code review, make sure > that we have tests > >> - to me a programmer should not compose slot property in the class > definition. > >> > > > > > > I will finish it and then we can discuss. > > > > Marcus > > > >
