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.
2007/5/4, Daniel Vainsencher danielv@tx.technion.ac.il:
Damien Cassou wrote:
Even with a new image, upgrading OB is currently not a good solution. This is because at least two installed packages (DynamicProtocols and OmniBrowserFixes) overrides some methods.
Ouch
Upgrading OB would then remove those overrides. I don't know what I can do for this :-(
Not include packages that include overrides?
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.
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?
For extensions, refactor them and the base package until the override is no longer needed.
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:*.
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...
Daniel