[ANN] Documentation for Omnibrowser

Damien Cassou wrote:
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. 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. [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

2007/5/7, Daniel Vainsencher <[hidden email]>:

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.



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