Hi Tudor, On Wed, May 18, 2016 at 09:26:51AM +0200, Tudor Girba wrote: > Hi, > > > On May 16, 2016, at 7:59 AM, Alistair Grant <akgrant0...@gmail.com> wrote: > > > > On Mon, May 16, 2016 at 05:42:54AM +0200, Tudor Girba wrote: > > > > ... > >> 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?
I'm porting my personal note taking system that I originally developed in Python / Django about 5 years ago to Pharo. The main entity is what I call a "meme", which simply has a name, label and description. Any number of attachments may be added, e.g. URLs, links to external files, internally managed files, etc. Meme's are related to each other as parents / children or peers. The approach I'm taking is to be able to view each of the objects in the standard Pharo inspectors, so for a meme its' name, label and description are displayed as formatted text with clickable links (thus the question that started this thread), relations to other memes are displayed in a RTMondrian force graph (at the moment). Being able to inspect the objects obviously helps with the debugging and gives the system a live / exploratory feel. Once that is working, I'll start on a more custom interface which will be more practical for actual note taking. Does that answer your question? Cheers, Alistair
