Bijan Parsia bparsia@email.unc.edu wrote:
[snip]
Oh yeah, and this is true for both True and False. So maybe we should just put this stuff in class Boolean, instead of duplicating it in two places.
Even more important IMHO is to always thing about that when reading a comment it should be self contained. That means we don't want to move parts of the comment to the superclass only because that part is true
for
multiple subclasses. If the part is really large, we might thing about
an
explicit "see superclass for more details" but othervise, I'd vote to a small redundancy in favor for comments you can understand without
knowing
the context. Keep in mind, the comment is for references not just a
part
of a larger explaination.
Even in the spirit of anti-redundancy, I do agree that comments should be reasonably non-fragmented. But actual duplication leads to a degree of maintenance pain. So perhaps an inclusion mechanism would be feasible? After all, we already have links, it can't be *that* hard to pull the actual text in.
Morph and its 245 subclasses would form a rather striking example.... Granted, True/False is just two clasess, and so it isn't such a big deal. IMHO, though, people reading Smalltalk code should just expect to have to look at the superclasses for the whole picture.
But of course, redundent comments are better than none. :)
Lex
I would vote for a simple connective phrase and a link to the superclass comment.
-david
-----Original Message----- From: Lex Spoon [mailto:lex@cc.gatech.edu] Sent: Tuesday, February 29, 2000 6:58 PM To: squeak@cs.uiuc.edu Subject: Re: [CCC] False class comment
Bijan Parsia bparsia@email.unc.edu wrote:
[snip]
Oh yeah, and this is true for both True and False. So maybe
we should
just put this stuff in class Boolean, instead of duplicating
it in two
places.
Even more important IMHO is to always thing about that when reading a comment it should be self contained. That means we don't want to move parts of the comment to the superclass only because that part is true
for
multiple subclasses. If the part is really large, we might
thing about
an
explicit "see superclass for more details" but othervise, I'd
vote to a
small redundancy in favor for comments you can understand without
knowing
the context. Keep in mind, the comment is for references not just a
part
of a larger explaination.
Even in the spirit of anti-redundancy, I do agree that comments
should be
reasonably non-fragmented. But actual duplication leads to a degree of maintenance pain. So perhaps an inclusion mechanism would be feasible? After all, we already have links, it can't be *that* hard to pull the actual text in.
Morph and its 245 subclasses would form a rather striking example.... Granted, True/False is just two clasess, and so it isn't such a big deal. IMHO, though, people reading Smalltalk code should just expect to have to look at the superclasses for the whole picture.
But of course, redundent comments are better than none. :)
Lex
squeak-dev@lists.squeakfoundation.org