[Pharo-users] GLMFormatedPresentation>>format bug?

Tudor Girba tudor at tudorgirba.com
Wed May 18 03:26:51 EDT 2016


Hi,

> On May 16, 2016, at 7:59 AM, Alistair Grant <akgrant0710 at gmail.com> wrote:
> 
> On Mon, May 16, 2016 at 05:42:54AM +0200, Tudor Girba wrote:
>> Hi,
>> 
>> 
>>    On May 16, 2016, at 1:00 AM, Ben Coman <btc at openInWorld.com> wrote:
>> 
>>    On Mon, May 16, 2016 at 6:28 AM, Alistair Grant <akgrant0710 at gmail.com>
>>    wrote:
>> 
>>        Hi Andrei,
>> 
>>        On Mon, May 16, 2016 at 12:08:01AM +0200, Andrei Chis wrote:
>> 
>>            Hi Alistair,
>> 
>>            Try something like this. Now 100% sure it will work.
>> 
>>            gtInspectIn: composite
>>                   <gtInspectorPresentationOrder: 30>
>> 
>>                   ^ composite text
>>                           title: 'Meme';
>>                           format: [self asText].
>> 
>>            The display block should return the object to be displayed, which
>>            is this case
>>            is self.
>> 
>> 
>>        Yep, that fixes the problem!  Thanks for your reply.
>> 
>> 
>>    Just curious if this also works...
>> 
>>            ^ composite text
>>                    title: 'Meme';
>>                    format: #asText
> 
> This also works, and looking at the definition of #format I'm guessing
> that this is closer to the original intended usage (see below)?
> 
> 
>> It works because the format block takes an optional argument with the input
>> entity. However, the semantics are not going to be quite the same. In
>> isolation, the behavior will be identical. However, the difference comes when
>> you try to reuse a presentation. 
>> 
>> Let’s look at an example. This is how an AST node displays the source:
>> 
>> RBProgramNode>>gtInspectorSourceCodeIn: composite
>> <gtInspectorPresentationOrder: 30> 
>> ^ composite pharoMethod 
>> title: 'Source code’;
>> display: [ self source ];
>> ...
>> 
>> Like this, the block closure can simply delegate to the corresponding ast node
>> to display the source:
>> 
>> BlockClosure>>gtInspectorSourceCodeIn: composite 
>> <gtInspectorPresentationOrder: 40>
>> self sourceNode gtInspectorSourceCodeIn: composite
>> 
>> And a keymap object which holds a block in an action instance variable, can
>> simply delegate to the block closure object to display the source:
>> 
>> KMKeymap>>gtInspectorSourceCodeIn: composite
>> <gtInspectorPresentationOrder: 30> 
>> ^ self action gtInspectorSourceCodeIn: composite
>> 
>> 
>> If the ProgramNode definition would have been implemented like:
>> display: [ :each | each source ]
>> 
>> then when inspecting the block object, we would have gotten the block object as
>> each, and not the AST node.
>> 
>> Does this explanation make sense?
> 
> So using this code is going to be more flexible than
> 
>    ^ composite text
>        title: 'Meme';
>        format: [self asText]
> 
> since the format object isn't supplied the optional arguments.

Actually, the less flexible approach is:
	format: [ :each | each source ]

Given that you define the extension directly in the class of the object you want to inspect, you essentially always want to apply the transformations on self, regardless of the “each” block argument. In this way, you can reuse this presentation in other objects through delegation like I mentioned above.

In any case, I am happy to hear that you want to extend you object. Could you let us know the use case?

Cheers,
Tudor


> Thanks,
> Alistair

--
www.tudorgirba.com
www.feenk.com

"Some battles are better lost than fought."








More information about the Pharo-users mailing list