On 15 Feb 2017, at 10:56, Ben Coman <btc@openinworld.com> wrote:

On Wed, Feb 15, 2017 at 3:38 PM, Alistair Grant <akgrant0710@gmail.com> wrote: I'm developing a number of classes where it would be convenient to be able to inspect what might be described as calculated attributes, i.e. the result of a unary message send. The result isn't stored in an instance variable, but is still useful when inspecting.

I can obviously develop an inspector extension for my application, but was wondering if there is a framework in place that allows a list of attributes to be declared that can also be inspected in a similar fashion to normal instance variables.

Many thanks to Doru and everyone who has contributed to the GT Inspector framework. It has significantly influenced my development and the architecture of the software I'm currently working on (in a positive way, of course).

Would it be feasible to have a "CalculationSlot" that was read only, and each time it was read it performed the calculation?

Using a “virtual” slot would be possible… it would look like a instance variable, (you can read from it and the calculation is done). I think it is a bit of overkill (and the machinery is a bit unused, so bugs will be found). Here is how this works: First we define a new kind of Instance Variable (we call them slots): Now enable the setting "Class Template with Slots” and you add a class like this: Slot subclass: #VirtualSlot slots: { #block } classVariables: { } category: 'Slot-Examples’ As you can see, it stores a block which es evaluated on read. So next, we need a setter: with: aBlock block := aBlock and a method that defines what happens of reading from such a strange var: read: anObject ^block value: anObject and as this is read only, write: aValue to: anObject self error: 'read only' and finally, a print method so it is rendered in the class definition view: printOn: aStream aStream store: self name; nextPutAll: ' => '; nextPutAll: self class name; nextPutAll: ' with: '; nextPutAll: block printString Object subclass: #TT slots: { #i => VirtualSlot with: [ :o | o class methods size ] } classVariables: { } category: ‘TT' add an accessor: i ^i and then you can to “TT new i”, add a second method and see how the value changes. And you can inspect “TT new” and you see that the i looks like a normal ivar. Marcus

On Wed, Feb 15, 2017 at 6:43 PM, denker <marcus.denker@inria.fr> wrote:

On 15 Feb 2017, at 11:24, denker <marcus.denker@inria.fr> wrote:

On 15 Feb 2017, at 10:56, Ben Coman <btc@openinworld.com> wrote:

On Wed, Feb 15, 2017 at 3:38 PM, Alistair Grant <akgrant0710@gmail.com> wrote: I'm developing a number of classes where it would be convenient to be able to inspect what might be described as calculated attributes, i.e. the result of a unary message send. The result isn't stored in an instance variable, but is still useful when inspecting.

I can obviously develop an inspector extension for my application, but was wondering if there is a framework in place that allows a list of attributes to be declared that can also be inspected in a similar fashion to normal instance variables.

Many thanks to Doru and everyone who has contributed to the GT Inspector framework. It has significantly influenced my development and the architecture of the software I'm currently working on (in a positive way, of course).

Would it be feasible to have a "CalculationSlot" that was read only, and each time it was read it performed the calculation?

Using a “virtual” slot would be possible… it would look like a instance variable, (you can read from it and the calculation is done).

I added this as an example to the Slot package:

https://pharo.fogbugz.com/f/cases/19709/add-example-ComputedSlot

Changes: - Name is “ComputedSlot” - added #= and #hash so changing the block is possible in the class definition - do not raise error but ignore writes to not interfere with object migration done by the class builder (e.g. when adding an ivar).

I will add that as an example to the image.

Very cool !! A good example would be calculation based on other instance variables. I took a guess... Object subclass: #TT slots: { #i. #j => VirtualSlot with: [ :o | o i + 1 ] } classVariables: { } category: 'AAAA' TT>> i ^i ifNil: [i:=0] TT>> i: i: number i := number TT>> j ^j In Playground... (tt := TT new) inspect. (tt i: 4) inspect. cheers -ben

On 15 February 2017 at 18:45, Sven Van Caekenberghe <sven@stfx.eu> wrote:

A custom extension is soo easy to do and will probably fit your expectations better. It would not be much more work than listing/indicating which attributes you want to display.

My original thought was to use method pragmas to tag the methods to be inspected. This would also provide a hint as to what the author was thinking when the code was written (that the method is more of an attribute of the object than an operation that can be performed). On 15 February 2017 at 20:56, Ben Coman <btc@openinworld.com> wrote:

Would it be feasible to have a "CalculationSlot" that was read only, and each time it was read it performed the calculation?

I have read about Slots but hadn't looked in to them before, more below. On 16 February 2017 at 00:18, denker <marcus.denker@inria.fr> wrote:

...

I added this as an example to the Slot package:

https://pharo.fogbugz.com/f/cases/19709/add-example-ComputedSlot

This will be in the next update.

Very cool !! A good example would be calculation based on other instance variables. I took a guess...

Object subclass: #TT slots: { #i. #j => VirtualSlot with: [ :o | o i + 1 ] } classVariables: { } category: 'AAAA'

TT>> i ^i ifNil: [i:=0]

TT>> i: i: number i := number

TT>> j ^j In Playground... (tt := TT new) inspect. (tt i: 4) inspect.

Yes! The block can not refer to instance variables, so for more complex compilations (or if one does not want to expose accessors), one might move the code to a “compute” method.

As an extension, it might be good to allow the Slot to be configured with a selector:

VirtualSlot with: #computeMyVar

This would just need some check in #read:.

Then of course, to speed things up one can do inlining by implementing #emitValue:, which could for the selector compile it to “self computeMyVar”.

Marcus

Many thanks for providing such a detailed example and especially getting it in to the base image so quickly (that's a record in my experience). At the moment I think that your suggested extension of configuring the slot with a selector may be better than supplying a block as it makes the code easier to read, i.e. the code is located in the method definition and not embedded the class definition. My inclination is to create a new type of slot, InspectorSlot or MethodSlot, that operates as you suggest rather than extending ComputedSlot. If you'd like this included, let me know, along with any suggestions for a better name, and I'll put together the fogbugz issue and slice. Thanks again, Alistair