Annotating instance variables
I saw some interesting reflection progress in Pharo 5. I wonder if there is a feature to rank instance variables. For example, from the browser I want to assign a category "important" to an instance variable, or "possibly useless", etc. for later refactorings. Is such thing "easily" possible now? There is API support from Reflectivity maybe? Cheers Hernán
On 11 Sep 2015, at 20:05, Hernán Morales Durand <hernan.morales@gmail.com> wrote:
I saw some interesting reflection progress in Pharo 5. I wonder if there is a feature to rank instance variables. For example, from the browser I want to assign a category "important" to an instance variable, or "possibly useless", etc. for later refactorings.
Is such thing "easily" possible now? There is API support from Reflectivity maybe?
The infrastructure is there⦠we can annotate instance variables. (Point slotNamed: #x) propertyAt: #note put: 'useless'. (Point slotNamed: #x) propertyAt: #note One could build a user interface around that. Properties are not saved with monticello, though. They are like method properties. So one would need to build something on top... Another idea would be to make a subclass of InstanceVariableSlot that stores the note in a property but it is actually part of the slot definition: Object subclass: #Point slots: { #x => InstanceVariableWithNote note: âthis is uselessâ. #y } classVariables: { } category: 'Kernel-BasicObjects' As the note is part of the slot definition, it would be saved in Monticello. (unrelated: I still am tempted to just use the term âinstance variableâ and get rid of the term Slot.. for the paper is was nice, but now? Especially as we have slot like first class ClassVars and Globals that nevertheless are not slotsâ¦) Marcus
Hi Marcus, Thanks for the answers. I am discovering Reflectivity, I just have a couple more questions if you don't mind: 2015-09-11 15:26 GMT-03:00 Marcus Denker <marcus.denker@inria.fr>:
On 11 Sep 2015, at 20:05, Hernán Morales Durand < hernan.morales@gmail.com> wrote:
I saw some interesting reflection progress in Pharo 5. I wonder if there is a feature to rank instance variables. For example, from the browser I want to assign a category "important" to an instance variable, or "possibly useless", etc. for later refactorings.
Is such thing "easily" possible now? There is API support from Reflectivity maybe?
The infrastructure is there⦠we can annotate instance variables.
(Point slotNamed: #x) propertyAt: #note put: 'useless'. (Point slotNamed: #x) propertyAt: #note
One could build a user interface around that.
This is cool, I just hope the Nautilus plugin interface is stable by now then :)
Properties are not saved with monticello, though. They are like method properties. So one would need to build something on top...
I don't know about MC model, but maybe extending MC to support properies/annotations could be a path?
Another idea would be to make a subclass of InstanceVariableSlot that stores the note in a property but it is actually part of the slot definition:
Object subclass: #Point slots: { #x => InstanceVariableWithNote note: âthis is uselessâ. #y } classVariables: { } category: 'Kernel-BasicObjects'
As the note is part of the slot definition, it would be saved in Monticello.
It could be silly question but most of the time I wish to annotate while debugging, using that option would affect my debugged objec state? Cheers, Hernán
(unrelated: I still am tempted to just use the term âinstance variableâ and get rid of the term Slot.. for the paper is was nice, but now? Especially as we have slot like first class ClassVars and Globals that nevertheless are not slotsâ¦)
Marcus
Properties are not saved with monticello, though. They are like method properties. So one would need to build something on top...
I don't know about MC model, but maybe extending MC to support properies/annotations could be a path?
Yes, that would be a possibility. Adding things to the monticello .zip is easy (and easy to ignore later/by others).
Another idea would be to make a subclass of InstanceVariableSlot that stores the note in a property but it is actually part of the slot definition:
Object subclass: #Point slots: { #x => InstanceVariableWithNote note: âthis is uselessâ. #y } classVariables: { } category: 'Kernel-BasicObjects'
As the note is part of the slot definition, it would be saved in Monticello.
It could be silly question but most of the time I wish to annotate while debugging, using that option would affect my debugged objec state?
No, the current class builder would migrate the objects (I think). As this does not change the shape of the instances, even that can be avoided. Marcus
On Sat, Sep 12, 2015 at 2:26 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 11 Sep 2015, at 20:05, Hernán Morales Durand <hernan.morales@gmail.com> wrote:
I saw some interesting reflection progress in Pharo 5. I wonder if there is a feature to rank instance variables. For example, from the browser I want to assign a category "important" to an instance variable, or "possibly useless", etc. for later refactorings.
Is such thing "easily" possible now? There is API support from Reflectivity maybe?
The infrastructure is there⦠we can annotate instance variables.
(Point slotNamed: #x) propertyAt: #note put: 'useless'. (Point slotNamed: #x) propertyAt: #note
One could build a user interface around that.
Properties are not saved with monticello, though. They are like method properties. So one would need to build something on top...
Another idea would be to make a subclass of InstanceVariableSlot that stores the note in a property but it is actually part of the slot definition:
Object subclass: #Point slots: { #x => InstanceVariableWithNote note: âthis is uselessâ. #y } classVariables: { } category: 'Kernel-BasicObjects'
As the note is part of the slot definition, it would be saved in Monticello.
(unrelated: I still am tempted to just use the term âinstance variableâ and get rid of the term Slot.. for the paper is was nice, but now? Especially as we have slot like first class ClassVars and Globals that nevertheless are not slotsâ¦)
Could you expand on how ClassVars and Globals are slot-like but not slots. One *tiny* consideration in favour of "slot" is that its more concise that "instance variable". Actually in post I often abbreviate to "iv" or "ivar". Also, would it be fair to say that for most programming languages variables are "dead", and it might be good to distinguish the "liveness" of slots. Further, there may be a particular class of early adopters who upon hearing the term "slot" that they don't know, will be compelled to investigate btw, can temporary variables be Slots? cheers -ben
Could you expand on how ClassVars and Globals are slot-like but not slots.
I mean in the sense that there are first class variables where I can make my own by subclassing. There is an object describing the var. For Global/Class variable this is the âbindingâ from the dictionary where they live. For class vars, in addition we have a syntax (same as slots) to declare in a class that you want to use such a âself madeâ variable. In the image there is an example (not a very useful one, more for testing the mechanism: LiteralVariable subclass: #ExampleClassVariable slots: { #state } classVariables: { } category: 'Slot-Examples' with methods: read ^state write: anObject state := anObject If you make a class with such a class var: Object subclass: #MyClass slots: { } classVariables: { #TT => ExampleClassVariable } category: âDemo' it compiles e.g. for a read: tt ^TT 21 <40> pushLit: global 22 <D1> send: read 23 <7C> returnTop
Also, would it be fair to say that for most programming languages variables are "dead", and it might be good to distinguish the "liveness" of slots. Further, there may be a particular class of early adopters who upon hearing the term "slot" that they don't know, will be compelled to investigate
btw, can temporary variables be Slots?
Temporaries have objects describing them (created on demand). You can annotate them (property interface), when you do that, the var is kept and you get this instance. There is a reflective API (#readInContext: and #write:InContext:). It would be possible to continue the implementation to allow subclassing (and have the compiler delegated code generation to them). This can be done as soon as we have the need. I wonder if there is a use case? What is not that easy is the syntax⦠of course one could have something like | #a => MyTemp . #b => MyTemp | but that is ugly. And a change to the syntax, which I want to avoid. Maybe a pragma? <tempClass: MyTemp forTemporaryNamed: #a> I think this should be use-case driven⦠Marcus
participants (4)
-
Ben Coman -
Hernán Morales Durand -
Marcus Denker -
Torsten Bergmann