2007/5/7, Daniel Vainsencher <danielv at tx.technion.ac.il>:
> Damien Cassou wrote:
> > 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?


I don't like that idea. CTRL+f means "find" to me. Not "find class". I
don't want to use two key strokes for finding classes or traits. What
do other people think? I don't want to choose for everybody.


> 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?


I perfectly agree and I think there are a lot of bugs due to this.


> 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.


This sounds like a good idea. However, there were a branch before and
it didn't work well. I will do it if others agree with you.


> > 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.


I noticed too :-) that's one of the reason I call this a ugly hack.


> 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.


Please do not confuse DynamicProtocols (which is a separate package,
like a plugin) and the OmniBrowserFixes. These are completely
different packages with different aims.

-- 
Damien Cassou