[Pharo4] Slots: API for Classes
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 ==> 5 Marcus
Very nice! Next would be an example of how to specialize a slot :) Doru On Wed, Jun 25, 2014 at 2:06 PM, Marcus Denker <marcus.denker@inria.fr> 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
==> 5
Marcus
-- www.tudorgirba.com "Every thing has its own flow"
On 25 Jun 2014, at 14:16, Tudor Girba <tudor@tudorgirba.com> wrote:
Very nice!
Next would be an example of how to specialize a slot :)
Yes, the next steps are: - introduce abstract superclass for Slot (I am not yet sure: will the be âSlotâ and the default slots are âInstVarSlotâ, or do I add a âAbstractSlotâ class and Slot stays the default? Maybe thatâs better) - Opal needs to delegate code generation to the Slot. - The abstract slot generates by default reflective read/write access code - subclasses can override. (e.g. the default slot overrides to do pushIvar/storeIvar bytecode) This is the enough to do behavioural changes to simple Slots. After that we need to check the code for âvirtualâ slots where e.g. multiple Boolean slots are mapped to one hidden flag ivar. And the of course - new class template (optional at first) - Monticello support Marcus
Am 25.06.2014 um 14:22 schrieb Marcus Denker <marcus.denker@inria.fr>:
On 25 Jun 2014, at 14:16, Tudor Girba <tudor@tudorgirba.com> wrote:
Very nice!
Next would be an example of how to specialize a slot :)
Yes, the next steps are:
- introduce abstract superclass for Slot
(I am not yet sure: will the be âSlotâ and the default slots are âInstVarSlotâ, or do I add a âAbstractSlotâ class and Slot stays the default? Maybe thatâs better)
I like the former better. But if you do can you please help stop that naming scheme? Could we name it InstanceVariableSlot then? Pleeeeaaaase? Norbert
- Opal needs to delegate code generation to the Slot.
- The abstract slot generates by default reflective read/write access code
- subclasses can override. (e.g. the default slot overrides to do pushIvar/storeIvar bytecode)
This is the enough to do behavioural changes to simple Slots.
After that we need to check the code for âvirtualâ slots where e.g. multiple Boolean slots are mapped to one hidden flag ivar.
And the of course
- new class template (optional at first) - Monticello support
Marcus
Slot \SimpleSlot (current iv slot) \CollectionSlot \BitmapSlot Esteban A. Maringolo 2014-06-25 9:38 GMT-03:00 Norbert Hartl <norbert@hartl.name>:
Am 25.06.2014 um 14:22 schrieb Marcus Denker <marcus.denker@inria.fr>:
On 25 Jun 2014, at 14:16, Tudor Girba <tudor@tudorgirba.com> wrote:
Very nice!
Next would be an example of how to specialize a slot :)
Yes, the next steps are:
- introduce abstract superclass for Slot
(I am not yet sure: will the be âSlotâ and the default slots are âInstVarSlotâ, or do I add a âAbstractSlotâ class and Slot stays the default? Maybe thatâs better)
I like the former better. But if you do can you please help stop that naming scheme? Could we name it InstanceVariableSlot then? Pleeeeaaaase?
Norbert
- Opal needs to delegate code generation to the Slot.
- The abstract slot generates by default reflective read/write access code
- subclasses can override. (e.g. the default slot overrides to do pushIvar/storeIvar bytecode)
This is the enough to do behavioural changes to simple Slots.
After that we need to check the code for âvirtualâ slots where e.g. multiple Boolean slots are mapped to one hidden flag ivar.
And the of course
- new class template (optional at first) - Monticello support
Marcus
On 25 Jun 2014, at 16:43, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
Slot \SimpleSlot (current iv slot)
Yes, the naming of that one⦠I think we just need to take the freedom of iterating. For now I called it âInstanceVariableSlotâ, but that might be confusing and it is a long word.
\CollectionSlot \BitmapSlot Esteban A. Maringolo
2014-06-25 9:38 GMT-03:00 Norbert Hartl <norbert@hartl.name>:
Am 25.06.2014 um 14:22 schrieb Marcus Denker <marcus.denker@inria.fr>:
On 25 Jun 2014, at 14:16, Tudor Girba <tudor@tudorgirba.com> wrote:
Very nice!
Next would be an example of how to specialize a slot :)
Yes, the next steps are:
- introduce abstract superclass for Slot
(I am not yet sure: will the be âSlotâ and the default slots are âInstVarSlotâ, or do I add a âAbstractSlotâ class and Slot stays the default? Maybe thatâs better)
I like the former better. But if you do can you please help stop that naming scheme? Could we name it InstanceVariableSlot then? Pleeeeaaaase?
Norbert
- Opal needs to delegate code generation to the Slot.
- The abstract slot generates by default reflective read/write access code
- subclasses can override. (e.g. the default slot overrides to do pushIvar/storeIvar bytecode)
This is the enough to do behavioural changes to simple Slots.
After that we need to check the code for âvirtualâ slots where e.g. multiple Boolean slots are mapped to one hidden flag ivar.
And the of course
- new class template (optional at first) - Monticello support
Marcus
On 25 Jun 2014, at 11:49, Marcus Denker <marcus.denker@inria.fr> wrote:
On 25 Jun 2014, at 16:43, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
Slot \SimpleSlot (current iv slot)
Yes, the naming of that one⦠I think we just need to take the freedom of iterating. For now I called it âInstanceVariableSlotâ, but that might be confusing and it is a long word.
but is less confusing than âSimpleSlotâ, which basically says nothing, IMO
\CollectionSlot \BitmapSlot Esteban A. Maringolo
2014-06-25 9:38 GMT-03:00 Norbert Hartl <norbert@hartl.name>:
Am 25.06.2014 um 14:22 schrieb Marcus Denker <marcus.denker@inria.fr>:
On 25 Jun 2014, at 14:16, Tudor Girba <tudor@tudorgirba.com> wrote:
Very nice!
Next would be an example of how to specialize a slot :)
Yes, the next steps are:
- introduce abstract superclass for Slot
(I am not yet sure: will the be âSlotâ and the default slots are âInstVarSlotâ, or do I add a âAbstractSlotâ class and Slot stays the default? Maybe thatâs better)
I like the former better. But if you do can you please help stop that naming scheme? Could we name it InstanceVariableSlot then? Pleeeeaaaase?
Norbert
- Opal needs to delegate code generation to the Slot.
- The abstract slot generates by default reflective read/write access code
- subclasses can override. (e.g. the default slot overrides to do pushIvar/storeIvar bytecode)
This is the enough to do behavioural changes to simple Slots.
After that we need to check the code for âvirtualâ slots where e.g. multiple Boolean slots are mapped to one hidden flag ivar.
And the of course
- new class template (optional at first) - Monticello support
Marcus
2014-06-25 11:52 GMT-03:00 Esteban Lorenzano <estebanlm@gmail.com>:
On 25 Jun 2014, at 11:49, Marcus Denker <marcus.denker@inria.fr> wrote:
On 25 Jun 2014, at 16:43, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
Slot \SimpleSlot (current iv slot)
Yes, the naming of that one⦠I think we just need to take the freedom of iterating. For now I called it âInstanceVariableSlotâ, but that might be confusing and it is a long word.
but is less confusing than âSimpleSlotâ, which basically says nothing, IMO
What about SimpleInstanceVariableSlot? (just kidding) I don't like over descriptive class names. Because they restrict you from using it for other, unexpected, purposes or contexts. Regards!
Am 25.06.2014 um 16:55 schrieb Esteban A. Maringolo <emaringolo@gmail.com>:
2014-06-25 11:52 GMT-03:00 Esteban Lorenzano <estebanlm@gmail.com>:
On 25 Jun 2014, at 11:49, Marcus Denker <marcus.denker@inria.fr> wrote:
On 25 Jun 2014, at 16:43, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
Slot \SimpleSlot (current iv slot)
Yes, the naming of that one⦠I think we just need to take the freedom of iterating. For now I called it âInstanceVariableSlotâ, but that might be confusing and it is a long word.
but is less confusing than âSimpleSlotâ, which basically says nothing, IMO
What about SimpleInstanceVariableSlot? (just kidding)
I don't like over descriptive class names. Because they restrict you from using it for other, unexpected, purposes or contexts.
The question to me is why this is "over descriptive". We have a tradition here to be descriptive and intention revealing. It happens everywhere except when it comes to instance variables it is instVarAt: instVarNamed: etc. I never liked them. Another question might be the usage context. Why is it called InstanceVariableSlot anyway? Is there a difference if the slot is attached to the instance side or class side? Isn't it really just a VariableSlot? The context for the instance is where it is used. Asking an object for instance variables and class instance variables could just return a collection of VariableSlots, no? Norbert
2014-06-25 12:06 GMT-03:00 Norbert Hartl <norbert@hartl.name>:
Am 25.06.2014 um 16:55 schrieb Esteban A. Maringolo <emaringolo@gmail.com>: I don't like over descriptive class names. Because they restrict you from using it for other, unexpected, purposes or contexts.
The question to me is why this is "over descriptive". We have a tradition here to be descriptive and intention revealing. It happens everywhere except when it comes to instance variables it is instVarAt: instVarNamed: etc. I never liked them.
I agree with you here, it is like those instVar* selectors are obfuscated only to show they are "low level stuff".
Another question might be the usage context. Why is it called InstanceVariableSlot anyway? Is there a difference if the slot is attached to the instance side or class side? Isn't it really just a VariableSlot? The context for the instance is where it is used. Asking an object for instance variables and class instance variables could just return a collection of VariableSlots, no?
"Simplicity is the ultimate sophistication", so finding a good intention revealing selector is not an easy task. But IMO the naming is as important as other factors, because you'll keep referring them in many contexts, and that will help build good mental models. I like how VariableSlot sounds. But aren't slots meant to be used always in the context of variables? If so, Variable might be read as an attribute (that varies, in shape, etc.). Many of us are non native speakers, so this is an important factor too. Regards!
On 25 juin 2014, at 17:06, Norbert Hartl <norbert@hartl.name> wrote:
Am 25.06.2014 um 16:55 schrieb Esteban A. Maringolo <emaringolo@gmail.com>:
2014-06-25 11:52 GMT-03:00 Esteban Lorenzano <estebanlm@gmail.com>:
On 25 Jun 2014, at 11:49, Marcus Denker <marcus.denker@inria.fr> wrote:
On 25 Jun 2014, at 16:43, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
Slot \SimpleSlot (current iv slot)
Yes, the naming of that one⦠I think we just need to take the freedom of iterating. For now I called it âInstanceVariableSlotâ, but that might be confusing and it is a long word.
but is less confusing than âSimpleSlotâ, which basically says nothing, IMO
What about SimpleInstanceVariableSlot? (just kidding)
I don't like over descriptive class names. Because they restrict you from using it for other, unexpected, purposes or contexts.
The question to me is why this is "over descriptive". We have a tradition here to be descriptive and intention revealing. It happens everywhere except when it comes to instance variables it is instVarAt: instVarNamed: etc. I never liked them. Another question might be the usage context. Why is it called InstanceVariableSlot anyway? Is there a difference if the slot is attached to the instance side or class side?
No indeed there is no difference, an iv slot attached to the class side is still an instance variable slot that happens to be declared in a metaclass and assigned in its unique instance and in its many subinstances.
Isn't it really just a VariableSlot?
It sounds too generic to me as custom slots can represent other kind of variables like class-variables: ClassSlot>>read: anObject ^ value ClassSlot>>write: anObject to: aValue value := aValue Note that iv slots are the default kind of slot, so no matter how long it seems to type InstanceVariableSlot, you won't have to type it. For example the current class builder can be used like this: PharoClassInstaller make: [ :builder | builder name: #MyClass; slots: { #a. #b => CustomSlot } ]. #a will be a slot of the default kind (currently named Slot) and #b will be a CustomSlot.
The context for the instance is where it is used. Asking an object for instance variables and class instance variables could just return a collection of VariableSlots, no?
Norbert
Hi. On Wed, Jun 25, 2014 at 8:06 AM, Norbert Hartl <norbert@hartl.name> wrote:
Am 25.06.2014 um 16:55 schrieb Esteban A. Maringolo <emaringolo@gmail.com
:
2014-06-25 11:52 GMT-03:00 Esteban Lorenzano <estebanlm@gmail.com>:
On 25 Jun 2014, at 11:49, Marcus Denker <marcus.denker@inria.fr> wrote:
On 25 Jun 2014, at 16:43, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
Slot \SimpleSlot (current iv slot)
Yes, the naming of that one⦠I think we just need to take the freedom of iterating. For now I called it âInstanceVariableSlotâ, but that might be confusing and it is a long word.
but is less confusing than âSimpleSlotâ, which basically says nothing, IMO
What about SimpleInstanceVariableSlot? (just kidding)
I don't like over descriptive class names. Because they restrict you from using it for other, unexpected, purposes or contexts.
The question to me is why this is "over descriptive". We have a tradition here to be descriptive and intention revealing. It happens everywhere except when it comes to instance variables it is instVarAt: instVarNamed: etc. I never liked them. Another question might be the usage context. Why is it called InstanceVariableSlot anyway? Is there a difference if the slot is attached to the instance side or class side? Isn't it really just a VariableSlot? The context for the instance is where it is used. Asking an object for instance variables and class instance variables could just return a collection of VariableSlots, no?
Instances have instanceVariables, and classes have instanceVariables. There are also ClassVariables, which are a completely different thing (and commonly referred to directly from instance, class, and subclasses directly). It would be good not to make this any more complex (confusing?) than those concepts already are. -cbc
Norbert
On 25 Jun 2014, at 14:22, Marcus Denker <marcus.denker@inria.fr> wrote:
On 25 Jun 2014, at 14:16, Tudor Girba <tudor@tudorgirba.com> wrote:
Very nice!
Next would be an example of how to specialize a slot :)
Yes, the next steps are:
- introduce abstract superclass for Slot
For now there is a subclass InstanceVariableSlot, all Slot instances have been migrated.
- Opal needs to delegate code generation to the Slot.
This is now done. Opal now, in the semantic analysis phase, annotates slot accesses as OCSlotVariable (OCInstanceVariable we can remove later). Then when generating, it just forwards to the slot: emitStore: methodBuilder slot emitStore: methodBuilder To allow Slots subclasses to be implemented without knowledge of bytecode, the next thing to add it the fallback:
- The abstract slot generates by default reflective read/write access code
Marcus
On 25 Jun 2014, at 17:15, Marcus Denker <marcus.denker@inria.fr> wrote:
- Opal needs to delegate code generation to the Slot.
This is now done. Opal now, in the semantic analysis phase, annotates slot accesses as OCSlotVariable (OCInstanceVariable we can remove later).
Then when generating, it just forwards to the slot:
emitStore: methodBuilder
slot emitStore: methodBuilder
This is now finally in the image 4.0 046 Marcus
Thanks for taking care, these things are aways more work than expected. On 26 Jun 2014, at 15:06, Marcus Denker <marcus.denker@inria.fr> wrote:
On 25 Jun 2014, at 17:15, Marcus Denker <marcus.denker@inria.fr> wrote:
- Opal needs to delegate code generation to the Slot.
This is now done. Opal now, in the semantic analysis phase, annotates slot accesses as OCSlotVariable (OCInstanceVariable we can remove later).
Then when generating, it just forwards to the slot:
emitStore: methodBuilder
slot emitStore: methodBuilder
This is now finally in the image 4.0 046
Marcus
On 26 Jun 2014, at 15:19, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Thanks for taking care, these things are aways more work than expected.
Indeed⦠and the code afterwards always looks so little and so simple ;-) Marcus
On 26 Jun 2014, at 15:06, Marcus Denker <marcus.denker@inria.fr> wrote:
On 25 Jun 2014, at 17:15, Marcus Denker <marcus.denker@inria.fr> wrote:
- Opal needs to delegate code generation to the Slot.
This is now done. Opal now, in the semantic analysis phase, annotates slot accesses as OCSlotVariable (OCInstanceVariable we can remove later).
Then when generating, it just forwards to the slot:
emitStore: methodBuilder
slot emitStore: methodBuilder
This is now finally in the image 4.0 046
Marcus
On 25 juin 2014, at 14:06, Marcus Denker <marcus.denker@inria.fr> 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
On 25 Jun 2014, at 17:32, Camille Teruel <camille.teruel@gmail.com> wrote:
On 25 juin 2014, at 14:06, Marcus Denker <marcus.denker@inria.fr> 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
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:
At least this is clear and I like that.
but nice it is not⦠or we maybe we use #resolveSlot: as the layoutâ¦.
Marcus
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
On 25 Jun 2014, at 14:06, Marcus Denker <marcus.denker@inria.fr> 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
As Camille noted, we need a different API on the Objects to read and write slots. We came up with: #readSlot: #readSlotNamed: #writeSlot:value: #writeSlotNamed:value: #writeToSlot:of: (this is what the compiler generates to reflectively write a slot) e.g. 5@3 readSlot: (Point slotNamed: #x) 5@3 writeSlotNamed: #x value: 7 This is in the issue tracker: https://pharo.fogbugz.com/f/cases/13418/reflective-API-for-Slots-on-Object Marcus
I like these names. Doru On Thu, Jun 26, 2014 at 4:38 PM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 25 Jun 2014, at 14:06, Marcus Denker <marcus.denker@inria.fr> 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
As Camille noted, we need a different API on the Objects to read and write slots.
We came up with:
#readSlot: #readSlotNamed: #writeSlot:value: #writeSlotNamed:value: #writeToSlot:of: (this is what the compiler generates to reflectively write a slot)
e.g.
5@3 readSlot: (Point slotNamed: #x) 5@3 writeSlotNamed: #x value: 7
This is in the issue tracker: https://pharo.fogbugz.com/f/cases/13418/reflective-API-for-Slots-on-Object
Marcus
-- www.tudorgirba.com "Every thing has its own flow"
participants (10)
-
Camille Teruel -
Chris Cunningham -
Esteban A. Maringolo -
Esteban Lorenzano -
Marcus Denker -
Norbert Hartl -
stepharo -
Sven Van Caekenberghe -
Torsten Bergmann -
Tudor Girba