[ENH] printName

[Brian Rice]

On Feb 26, 2005, at 1:28 PM, Levente Mészáros wrote:

> I think we should consider enhancing the printName facility. Although 
> I don't have concrete suggestions for the names, but I do have for the 
> things which should have separate names.

Cool; I like the thought you put into this, and it's bugged me as well 
(since you brought the issue up on IRC).

> I did the following naming test:
>
> object@(Root traits) setPrintName: name
> [
> 	object addImmutableSlot: #printName valued: name.
> ].
> object@(Root traits) setPrintNames: name
> [
> 	object setPrintName: name.
> 	object traits setPrintName: (name ; ' shared behavior').
> 	object traitsWindow setPrintName: (name ; ' ???').
> ].
>
> MapComposition setPrintNames: 'MapComposition'.
> Mapping setPrintNames: 'Mapping'.
> Cloneable setPrintNames: 'Cloneable'.
> Derivable setPrintNames: 'Derivable'.
> Root setPrintNames: 'Root'.

These are an interesting start. In this case you could use printName: 
instead of setPrintName: since an immutable slot won't override it.

> Having this naming scheme (of course it would be done by 
> addPrototype:) and a small slate program I could do the following:
>
> Slate 1> load: 'src/plugins/ing/ing.slate'.
> Loading 'src/plugins/ing/ing.slate'
> Nil
> Slate 2> Ing collectFrom: MapComposition.
> digraph g {
> node[shape=record];
> 10[label="{Cloneable shared behavior|10}"];
> 11[label="{Cloneable ???|11}"];
> 1[label="{Root shared behavior|1}"];
> 2415543[label="{MapComposition|2415543}"];
> 2873333[label="{MapComposition ???|2873333}"];
> 7910635[label="{MapComposition shared behavior|7910635}"];
> 7[label="{Derivable shared behavior|7}"];
> 3337578[label="{Mapping shared behavior|3337578}"];
> 2415543 -> 2873333[label="{traitsWindow|329}"];
> 2873333 -> 11[label="{traitsWindow|329}"];
> 11 -> 11[label="{traitsWindow|329}"];
> 11 -> 1[label="{traits2|465}"];
> 1 -> 11[label="{traitsWindow|329}"];
> 11 -> 7[label="{traits1|383}"];
> 7 -> 11[label="{traitsWindow|329}"];
> 11 -> 10[label="{traits|349}"];
> 10 -> 11[label="{traitsWindow|329}"];
> 2873333 -> 1[label="{traits4|615}"];
> 2873333 -> 7[label="{traits3|625}"];
> 2873333 -> 10[label="{traits2|465}"];
> 2873333 -> 3337578[label="{traits1|383}"];
> 3337578 -> 11[label="{traitsWindow|329}"];
> 2873333 -> 7910635[label="{traits|349}"];
> 7910635 -> 11[label="{traitsWindow|329}"];
> }
> Nil
> Slate 3> MapComposition.
> ("MapComposition" traitsWindow: ("MapComposition ???" traitsWindow: 
> ("Cloneable ???" ...).
>         traits4: ("Root shared behavior" ...). traits3: ("Derivable 
> shared behavior" ...).
>         traits2: ("Cloneable shared behavior" ...). traits1: ("Mapping 
> shared behavior" ...).
>         traits: ("MapComposition shared behavior" ...). printName: 
> 'MapComposition ???').
>     base: ("Mapping ???" traitsWindow: ("Mapping ???" ...)). diff: 
> Nil. printName: 'MapComposition')
>
> Slate 4>
>
> The graph above can be drawn via GraphViz, see attachment. I think the 
> names written on the console for MapComposition looks better.

It certainly does look better.

> What do you think?

It's not bad at all. If I were to incorporate it, I'd set it up so that 
derive automatically re-uses these methods, and also we'd still have to 
use pre-load.slate to initialize the bootstrap-defined types 
(cloneable, deriveable, etc.).

I will definitely consider it but I want as well to improve our Path 
object support so we can get good path names to objects (as opposed to 
now where the depth-first search just finds /something/ and hands back 
that first success, regardless of how helpful  or canonical it is). I'd 
also like to know what others think.

--
Brian T. Rice
LOGOS Research and Development
http://tunes.org/~water/