2007/5/5, Daniel Vainsencher <danielv at tx.technion.ac.il>:
> Damien Cassou wrote:
> > If you have time and solutions, you can commit to OmniBrowser,
> > OmniBrowserFixes and DynamicProtocols. They are all open to
> > modifications.
>
> If you help me get into it, I'll have a look and see if I can help.
> Overrides are evil, and I'd like to help kill them.


Please ask any specific question you might have.

OmniBrowser repository: http://source.wiresong.ca/ob
OmniBrowser fixes: http://www.squeaksource.com/OmniBrowserFixes/


> > 2007/5/4, Daniel Vainsencher <danielv at tx.technion.ac.il>:
> >> Damien Cassou wrote:
> > Sometimes there is no other solution than doing an override.
> I doubt that - the world of possible solutions is so large. Do you want
> to talk about a particular example?Sorry, I can't, so I have only opinions.


You are right. There is always a solution. Sometimes, it's not that
easy to implement however. 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.
   ...

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?

> > 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. So, it's not an override anymore.
However, I have to manually get the nodes I want from the root. I
didn't have this problem before because I added the line installing
the dynamic protocols directly in OBCodeBrowser>>addTo*

> > OBSystemBrowser>>addTo: root class: classSel comment: commentSel
> > metaclass: metaclassSel
> >     "Adds the dynamic protocols to the metagraph"
> >     |class metaclass method|
> >     super addTo: root class: classSel comment: commentSel metaclass:
> > metaclassSel.
> >
> >     "Get back the meta nodes from the root. Really ugly"
> >     class := root children detect: [:node | node name =  'Class'].
> >     metaclass := root children detect: [:node | node name =
> > 'Metaclass'].
> >     method := class children anyOne children first.
> >
> >     DynamicProtocols
> >         installDPOnClass: class
> >         metaClass: metaclass
> >         method: method.
> >     ^ root
> >
> > I have exactly the same code in OBHierarchyBrowser. It can be enhanced
> > a bit but I think a bigger refactoring is needed in methods creating
> > metagraphs.
> >
> >
>
> Nor does OBHB have code that looks like that in this image. Give me a
> specific image, package, class and overriding method, and preferably an
> explanation why its needed, and I'll see if there's anything I'd do
> different. At the minimum, we'll all learn something about a difficult
> packaging subject...

Is it clearer now ? 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.

Hope you can help.

Bye

-- 
Damien Cassou