On Oct 22, 2008, at 4:36 PM, Lukas Renggli wrote:
"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?
would be nice to know do whom I'm replying. But still there is a value in knowing that the method is doing a super call or not. The indicator means that the method use the keyword "super". So this is valuable. I really think that you are really kind of criticizing. When I browse code this arrow helps me. This is the same with the requireemnts analysis nathanael did in the old traits image Download the OOPSLA refactoring image and you can see that using is browser you can ****see**** methods sending messages not implemented. just in front of your nose.
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.
Documentation more than anything else. I imagine that like most of colin code there is not one line of comments which is sad because people make mistakes.
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 sad too. The problem is that if the system does not offer incentive and that you do not see the immediate benefits then you do not do it. This is why I would really like to see a package manifesto supporting design, styles rules checking, test regressions results so that the incentive to write code with documentation and tests is raised.
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.