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. > > ==> 5 > > Marcus
