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).
Yes
being precise about the api would greatly help.
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 :)
valueOfSlotNamed: is not that bad.
Having a clean and consistent API would be great.
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.
+1
==> 5
Marcus
