>> "Icons that show different concepts (and calling >> super and overriding a method are entirely different concepts, as well >> as putting a breakpoint or deprecating a method) and that hide each >> other are evil." > > Absolutely agree, hence that design. And in any case calling super is a > stupid indicator, especially when you know that it doesn't check that the > super call is a) to the same method or b) on every call path. The indicator > actually means 'might call some method declared in a superclass', which of > course you can easily do by calling a method that isn't overridden in the > declaring class, so what the hell use is that?
Thank you for expressing it that clearly ;-) > OB is a good prototype, although IMO I disagree. I exclusively use OB in productive development on a daily bases for over 2 years now. > b) shouldn't include any action abstraction because that's best > handled in a completely different and system-wide fashion; I disagree. OB provides this system-wide abstraction. It is the fault of the other tools that don't use these abstractions. For example, I've written a process browser, debugger, inspector and several other tools in OB and they all benefit from the commands that already exist and that other people write as extensions (e.g. open a hierarchy browser from within the debugger). I agree that the abstraction is not optimal in all cases (e.g. text commands, applicability tests, ...), but it is definitely better than anything else I've seen so far. > different and system-wide fashion; c) is too messily tied to Morphic, with a > number of hacks; and relatedly, d) shouldn't extend existing Morphic > controls (such as lists) because they come with too much baggage (i.e. being > all things to all people). Earlier versions of OB were entirely separated from Morphic. Unfortunately it was tied to morphic over time as more and more people joined the development. I guess this happend due to laziness and lack of documentation and knowledge. Along the same lines: Every line of the model and view used to be tested with in-depth SUnit-Tests. Unfortunately that is not the case anymore either. People add features without writing tests. This is what happens, when an appealing and widely adapted projects entirely lacks a form of leadership. At some point there was an AJAX based web view and a XUL interface. I think somebody even made GTK view. Earlier versions of OB run in GemStone, with the view running in Squeak Morphic. There is an ongoing port for GST. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
