Smalltalk › Pharo › Pharo Smalltalk Users

Inspecting calculated attributes

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

8 messages Options

alistairgrant

Inspecting calculated attributes

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).

Thanks,
Alistair

Sven Van Caekenberghe-2

Re: Inspecting calculated attributes

> On 15 Feb 2017, at 08:38, Alistair Grant <[hidden email]> 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.

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.

> 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).
>
>
> Thanks,
> Alistair
>

Ben Coman

Re: Inspecting calculated attributes

In reply to this post by alistairgrant

On Wed, Feb 15, 2017 at 3:38 PM, Alistair Grant <[hidden email]> 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?

cheers -ben

Marcus Denker-4

Re: Inspecting calculated attributes

> On 15 Feb 2017, at 10:56, Ben Coman <[hidden email]> wrote:
>
>
>
> On Wed, Feb 15, 2017 at 3:38 PM, Alistair Grant <[hidden email]> 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

Marcus Denker-4

Re: Inspecting calculated attributes

On 15 Feb 2017, at 11:24, denker <[hidden email]> wrote:

On 15 Feb 2017, at 10:56, Ben Coman <[hidden email]> wrote:

On Wed, Feb 15, 2017 at 3:38 PM, Alistair Grant <[hidden email]> 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.

Marcus

Ben Coman

Re: Inspecting calculated attributes

On Wed, Feb 15, 2017 at 6:43 PM, denker <[hidden email]> wrote:

On 15 Feb 2017, at 11:24, denker <[hidden email]> wrote:

On 15 Feb 2017, at 10:56, Ben Coman <[hidden email]> wrote:

On Wed, Feb 15, 2017 at 3:38 PM, Alistair Grant <[hidden email]> 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

In Playground...

(tt := TT new) inspect.

(tt i: 4) inspect.

cheers -ben

Marcus Denker-4

Re: Inspecting calculated attributes

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

alistairgrant

Re: Inspecting calculated attributes

On 15 February 2017 at 18:45, Sven Van Caekenberghe <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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