Re: [Pharo-project] NewInspector does not work well with delegated collections
what we learned in the story is that the newinspector is too intrusive and that we should make sure that we limit the api to be used when building introspective tools. This is also why we will remove it from the next pharo-dev Stef On Nov 29, 2010, at 9:38 PM, jaayer wrote:
Enclosed is a fileout of a sample collection named DelegatedSet that works by delegating to an instance of Set stored in an instance variable. It implements the basic protocol Collection requires, including #add:, #remove:ifAbsent: and #do: as well as some additional messages, all through delegation. Create an instance of it and then inspect that instance with NewInsepctor, and you will notice the "Elements" item does not work. Nothing happens when you click it. To inspect the elements, you need to click "set," the instance variable containing the Set, and then inspect that object further. Apparently, unless you override one or more messages under the extension category *Newinspector, NewInspector will not know how to inspect your collection properly. Worse, as soon as you do implement those methods, unless you change their category, they will now be considered part of the *Newinspector package rather than the package your collection belongs to and will not be saved along with the collection.
I think at a minimum, any collection understanding #do: and #size should be inspectable by NewInspector.<DelegatedSet.st>
---- On Tue, 30 Nov 2010 02:45:31 -0800 Stéphane Ducasse wrote ----
what we learned in the story is that the newinspector is too intrusive and that we should make sure that we limit the api to be used when building introspective tools. This is also why we will remove it from the next pharo-dev Stef
I didn't put this in my initial post, but the problem is even worse with collections like OrderedCollection, which reimplements NewInspector messages like #collect:displayingProgress: and #withIndexCollect:displayingProgress: because the implementations it inherits from SequenceableCollection use #at:put: rather than #add: to build a copy of the receiver. If you try to create your own OrderedCollection class by subclassing SequenceableCollection and forwarding to OrderedCollection, unless you forward the NewInspector messages too, in addition to the "Elements" tab not working, exceptions will be thrown.
On Nov 29, 2010, at 9:38 PM, jaayer wrote:
Enclosed is a fileout of a sample collection named DelegatedSet that works by delegating to an instance of Set stored in an instance variable. It implements the basic protocol Collection requires, including #add:, #remove:ifAbsent: and #do: as well as some additional messages, all through delegation. Create an instance of it and then inspect that instance with NewInsepctor, and you will notice the "Elements" item does not work. Nothing happens when you click it. To inspect the elements, you need to click "set," the instance variable containing the Set, and then inspect that object further. Apparently, unless you override one or more messages under the extension category *Newinspector, NewInspector will not know how to inspect your collection properly. Worse, as soon as you do implement those methods, unless you change their category, they will now be considered part of the *Newinspector package rather than the package your collection belongs to and will not be saved along with the collection.
I think at a minimum, any collection understanding #do: and #size should be inspectable by NewInspector.
participants (2)
-
jaayer -
Stéphane Ducasse