Rather than a mode for inspecting dictionaries, wouldn't it be better  
to have a subclass, say DictionaryInspector, which could be selected  
as needed by means of an #inspectorClass method. Then, if more  
specializations turn up, they could be added in the same way.

Just a thought that struck me.

--
Cheers,
Peter.

On 26 nov 2009, at 20.01, Stéphane Ducasse <stephane.duca...@inria.fr>  
wrote:

> Ok I will check.
> may be we can have a mode that does not provide object  
> interpretation (for dict we would only see
> tally and array not the dictionary, ...).
>
> Stef
>
> On Nov 26, 2009, at 7:40 PM, Adrian Lienhard wrote:
>
>> Just yesterday, I asked Frederic to remove the class and method
>> entries that add a lot of the noise and are most often not needed. He
>> committed a new version with these changes.
>>
>> But from Stef's analysis it seems there is a bit more needed to make
>> this inspector fly... And a really good inspector is key!
>>
>> Another item to add to Stef's list: what is the point of the item
>> "Keys"? I can see the keys of the dictionary already by opening
>> "Elements". So this seems superfluous.
>>
>> I wonder why inspecting a dictionary could not be reduced to the
>> information that is actually of interest, namely the keys and their
>> values. So when opening a dictionary, the subtree would directly
>> display the keys in the left pane (no array, tally, Keys, Elements).
>> If a key is selected, its value is printed in the right pane.
>> Expanding a key would dive into its associated value. Actually, I
>> think what I described here is more or less the behavior of the old
>> explore tool.
>>
>> Cheers,
>> Adrian
>>
>>
>> On Nov 26, 2009, at 18:39 , Stéphane Ducasse wrote:
>>
>>> Hi guys
>>>
>>> again I did a demo of smalltalk and the newInspecotr got in my way.
>>> I tried to analyze what did not work:
>>>    - apparently the refresh does not work. Does change in instance
>>> variables get refreshed in the inspector?
>>>
>>> I try to understand what get in my way in general.
>>>    - when an object has few instance variable I think that it is  
>>> lost
>>> in the sea of trees.
>>>
>>>    - I think that the |> class is not useful at the top level.
>>>    May be just having Class: and the class Name is enough no need  
>>> for
>>> the |>
>>>    May be the Class : ByteString should appear after the Elements:
>>>
>>>    - the |> methods to be useful should be sorted by category
>>>
>>> in the screenshot
>>>    Why do I see the instance variable of the  dictionary (array and
>>> tally) I find that confusing?
>>>    Because I get elements and at the same time the instance  
>>> variables.
>>>
>>>    I do not understand why some lines are bold and other blue
>>>
>>>    When we click on connectInfo I see on the right pane
>>>        - size : 5
>>>        [#host] : a SocketAddress (size: 24)
>>>        [#loginMethod] : #zork
>>>        [#password] : nil
>>>        [#port] : 110
>>>        [#user] : 'stephane.ducasse'
>>>    But I cannot modify anything.
>>>
>>>    What is the point to have Elements expanded in the left pane  
>>> when I
>>> get the contents by clicking on the instance
>>>    variable and getting the contents on the right.
>>>
>>>    Then Keys should probably close to Elements.
>>>
>>>    I do not see the point to have |> for individual method
>>>    I do not understand why we see Elements and ByteCode
>>>        I get a DNU when I click on Elements of a method BTW
>>>
>>>
>>>    <Screen shot 2009-11-26 at 6.14.31
>>> PM.png>_______________________________________________
>>> Pharo-project mailing list
>>> Pharo-project@lists.gforge.inria.fr
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Reply via email to