[ANN] Documentation for Omnibrowser

Daniel Vainsencher danielv at tx.technion.ac.il
Mon May 7 07:32:45 UTC 2007


Damien Cassou wrote:

>
>
> For example:
>
> OBCmdFindClass>>findClassIn: anEnvironment pattern: pattern
>   ...
>   potentialClassNames := anEnvironment classNames asArray.
>   ...
>
> I want the traits too in this variable. Do you have a better solution
> than my override:
>
> OBCmdFindClass>>findClassIn: anEnvironment pattern: pattern
>   ...
>   potentialClassNames := (anEnvironment classNames, anEnvironment
> traitNames) asArray.
>   ...
Why not separate out "find Trait" into its own command? user probably 
knows whether something is a trait or class due to the T prefix. BTW, 
this is a symptom of not having a concept Foo that is a supertype of 
"class" and "trait", and the obvious methods #isFoo, 
SystemDict>>fooNames and so forth. We really need this concept, and I 
would use Behavior, but that's taken to mean something else. Any ideas?
BTW, changing the semantics of the 'find class' action to also find 
traits just confuses things further by making more people assume that 
trait is a kind of class.
>
> If you have a better solution, please commit to the above
> repositories. I would really like to get rid of those overrides.
>
>
>> >> At least for fixes, move them into their intended permanent home...
>> >
>> > This is not possible because the fixes are trait-specific and OB must
>> > be backward compatible.
>>
>> Why is it better to maintain the fixes in parallel to the OB mainline as
>> overrides, rather than as a branch of the OB?
>
> I don't know. Why not :-) Is it possible to maintain a branch in a
> different repository? I think this would solve our overriding
> problems. Can you help me in this direction?
In MC, being a branch simply means that whoever maintains the "main" 
branch never merges your versions in. Instead, you always merge his 
versions. Thus technically, you could even maintain the branch in the 
same repository, though everyone else might find it confusing. So sure, 
use another repo for clarity. Probably the recommended way to go about 
this is to contribute all of your changes to the mainline, except that 
you maintain a very minimal branch with only the overrides. After 
mainline puts out a new version, you merge it into your branch, to 
produce a new version of the branch. Then (naturally) make sure that 
Universes use either only your branch, or only the mainline.
>
>> > I refactored DynamicProtocols so that I don't have an override for it
>> > anymore. The code is really ugly however.
>>
>> I don't feel I really understand this example. What I see below looks
>> like an override. Opening a squeak-dev 118 image, OBSB does not seem to
>> have a method #addTo:*.
>
> OBSB does not have this method currently. DynamicProtocols adds it to
> install itself in the browser.
[snip]
> The package DynamicProtocols has to modify the
> meta graph. I can do it when the meta graph is constructed in
> OBCodeBrowser>>addTo* but this would be an override. My current
> solution is to reimplement #addTo: in the subclasses I want:
> OBSystemBrowser and OBHierarchyBrowser.
I see. As Colin says, the problem you're confronting is pretty 
difficult, and I'll write on that separately. I will note however, that 
the new solution you're using only avoids overrides in a superficial 
sense. In fact, your upstream package could tomorrow choose to override 
(in the inheritance sense) this method in the subclasses, and you'd be 
back where you started. In fact, it could tomorrow add a new subclass 
overriding that method, and your overrides would then interfere 
significantly with its design. This strengthens my feeling that what you 
are currently maintaining is a branch, not an extension, of OB. To 
change this situation, OB needs better extensibility, as Colin says.

Daniel




More information about the Squeak-dev mailing list