[Pharo-users] GLMFormatedPresentation>>format bug?

Tudor Girba tudor at tudorgirba.com
Sun May 15 23:42:54 EDT 2016


> 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

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?


> cheers -ben


"Some battles are better lost than fought."

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/attachments/20160516/7fbf1114/attachment.html>

More information about the Pharo-users mailing list