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.
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
