customizing Object>>gtGsVariableValuePairsWithSelfIf: for GemStone

[dalehenrich]

I find that I want to add some synthetic fields for GemStone: oop and dependencyList are the two most pressing (see #38), but I am curious as to the best way to extend the method Object>>gtGsVariableValuePairsWithSelfIf: ... it is shared between Pharo and GemStone, so it looks like I need to wrap the GemStone-specific code with a #gtGsIsGemstone call ... but then I wonder how to handle competing additions to this method ... ???

Anyway, I think I can add what I need, but it seems that additional customizations can get a bit difficult to do without having different developers stomping on each other ...

[chisandrei]

Currently Object>>gtGsVariableValuePairsWithSelfIf: is only used on the GemStone side. All inspector presentations that use it have a #when block (when: [ self gtGsIsGemstone ]).

Right now, in the inspector the cleanest way would be to add a new custom presentation that displays the state the way you want. For example:

Object>>gtGsInspectorBRawTableWithSyntheticFieldsPresentationIn: aComposite
<gtInspectorPresentationOrder: 10>

   ^ self gtGsInspectorBRawTablePresentationIn: aComposite
        title: 'Raw Custom';
        display: [ 
           "self gtGsVariableValuePairsWithSelfIf: true" 
           "here the list of variables can be constructed by reusing or not gtGsVariableValuePairsWithSelfIf"]

What's not available now for the GemStone inspector is disabling presentations. For example, in Pharo you could add a custom Raw presentation and disable the default one.

But indeed we need a better mechanism for specifying synthetic fields. One solution that I had in mind is to have dedicated methods that construct a depend field start with a predefined name (#gtGsInspectorsyntheticFieldOop, #gtGsInspectorsyntheticDependencyList). The inspector could locate them by name and use then to when creating the 'Raw' view. I'm opened to other suggestions.

[dalehenrich]

Yeah, I'll have to think about that ... when I get some time :) ... with tODE I only have to subclass a builder to customize things ... these distributed methods make it somewhat hard for a developer to understand just what goes into making a view for now hard-wiring the synthetic fields will work for me ... THX

[chisandrei]

Indeed, some kind of builders could also work for the case of more complex presentations, like the Raw view. Need to also find time to look more into this :)