On 25 Jun 2014, at 17:32, Camille Teruel <[email protected]> wrote:
> > On 25 juin 2014, at 14:06, Marcus Denker <[email protected]> wrote: > >> Hi, >> >> Already in Pharo3 all instance variables are described using meta-objects >> (so called slots). >> >> To make it easier to access the slots, I added some simple methods to >> ClassDescription on 4.0 043, >> Now we can do e.g.: >> >> Context slots >> Context allSlots >> >> Point hasSlotNamed: #x >> Point slotNamed: #x >> >> e.g. the slot “x” of Point knows how to reflectively read itself from a >> point: >> >> (Point slotNamed: #x) read: 5@3 > > Now we should be careful that the reflective APIs for slots at object-level > and at class-level don't clash. > What I means is that if "Point slotNamed: #x" return a slot what is the > selector that satisfies "Point ?: #superclass" --> Object. > > It's difficult to have an elegant and consistent naming scheme because we > lack precise terminology. > For example when we talk about an instance variable, do we refer to the > declaration of an iv in a class or to the value bound to an iv in a given > instance of that class? > Right now it is not clear: compare current class-level reflective API > (#hasInstVarNamed: #instVarNames & co) to the object-level one > (#instVarNamed: #instVarNamed:put: & co). > I'm afraid that if we don't pay attention, we will have the same confusion > when talking about slots. > > A slot is the *specification* of a variable that is accessible to the > instances of a class. > So I think that the term slot should be reserved for methods of the > class-level reflective API, as Marcus proposes with these new methods. > > So now what should be the new reflective API at the object-level? > Note that a slot doesn't necessarily define an instance variable, a slot > could represent a shared variable like a class variable for example. > So I'm not sure that #instVarNamed: and #instVarNamed:put are still good > names (even if they are backward compatible)... > Maybe #variableNamed: and #variableNamed:put:? > Or #valueOfSlotNamed: and #setValueOfSlotNamed:to:? > I think I dislike both, so I hope you have better ideas :) > > Sorry to be the annoying nitpicker :), I know I tend to be fussy with > terminology. > But terminology determines APIs: ill-defined terminology is a step towards > bad APIs. > Yes… the problem is that the “Slot meta object” and the “Slot that stores something” use the same name… this was not a problem for instance variables as the where not reified. maybe on the class side it could be Point slotDefinitionNamed: but nice it is not… or we maybe we use #resolveSlot: as the layout…. Marcus
