Re: CLOS and C++
From: Peter Seibel (peter_at_javamonkey.com)
Date: 11/25/03
- Next message: Steven E. Harris: "Re: CLOS and C++"
- Previous message: Anthony Ventimiglia: "Re: (sqrt (factorial 100))"
- In reply to: james anderson: "Re: CLOS and C++"
- Next in thread: james anderson: "Re: CLOS and C++"
- Reply: james anderson: "Re: CLOS and C++"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 25 Nov 2003 21:28:28 GMT
james anderson <james.anderson@setf.de> writes:
> Peter Seibel wrote:
> >
> > james anderson <james.anderson@setf.de> writes:
> >
> > ...
> > >
> > > do java declarations provide anything which cl declarations do not?
> >
> > Well, the main thing is they're always there--you always know what
> > type of arguments a method expects and what type it returns. Also
> > declarations include information about what exceptions (conditions) a
> > method may throw.
> >
>
> fess up now, (and no crossing your fingers): in your expereince, what was the
> relative percentage of needing to know the exceptions a given method can raise
> a - in order to handle them v/s
> b - in order to declare something more sensible than Throwable.
50/50 maybe. Hard to say--is catching an exception and then rethrowing
a new exception of a different type handling it? There's a lot of that
because of the need to preserve abstraction boundaries. Exceptions are
definitely part of the public interface of any code that can throw
them, whether or not the language forces you to explicitly handle them
or not.
I much prefer CL conditions exactly because not every intermediate
layer needs to be involved in handling and/or propagating conditions.
However, it is good to have a way (and actually it seems more
important in a system where you *don't* have to do anything explicit
to pass on a condition/exception) to easily find out what conditions
can come percolating up out of the depths of your program. (Other than
inspecting all source code I mean. Especially if you're using third
party libraries.)
> > Indeed. They are called javadoc "comments" for a reason. What the
> > javadoc tool does is combine the comments (which have some
> > internal structure but are otherwise just human readable text)
> > with the information provided by the mandatory type declarations.
>
> to take my original question another round, is there anything
> allowed by javadoc comment which one could not determine through a
> combination of introspection and declaration?
If by introspection you mean the facilities currently provided by
java.lang.reflect.*, the answer is yes. The comments are human
readable text and are neither declarations and nor available via
reflection. Now, you could change the compiler to extract the text in
javadoc comments and put it into the class file and then change the
reflection classes to give you access to that information and then it
would be available via "introspection". But I don't think that's what
you meant, is it?
> wrt the core javadoc properties one would need an additional
> declaration name for conditions signaled, and, should one feel
> possessed to, could do so as well for author and version. given
> which, any documentation text could be analysed and marked up
> dynamically, without the maintenace overhead which javadoc comments
> entail. perhaps eclipse has improved on visual-age, but in my memory
> comments were an embarassingly poor step-child.
No doubt. It's definitely a tricky balancing act. One ideal is to
attach the documentation directly to the elements its documenting so
the docs stay in sync and so you don't have to duplicate information
(such as names) to establish the connections. On the other hand,
putting too much documentation in line obscures the code. Javadoc, for
instance, strikes this balance by requiring method-level comments to
be "attached" to the methods by immediately preceding them. But the
parameters to the method are documented by reference.:
/**
* Compute the factorial of n.
*
* @param n A non-negative integer.
*/
public int factorial(int n) {
if (n == 0) {
return 1;
} else {
return n * factorial(1 - n);
}
}
As opposed to say:
/**
* Compute the factorial of n.
*/
public int factorial(int n /** A non-negative integer.*/) {
if (n == 0) {
return 1;
} else {
return n * factorial(1 - n);
}
}
which saves a bit of duplication at the cost of cluttering up the
actual code. Or they could have gone the other direction and allowed
all the method-level comments to be gather up at the top of the file
like this at the cost of duplicating the whole method signature:
/**
* Compute the factorial of n.
*
* @param n A non-negative integer.
*/
public int factorial(int n);
How exactly to strike the balance depends on what kind of information
you can extract automatically from the code, the syntax of the
language, and what kind of tools folks are going to be using to edit
code.
-Peter
--
Peter Seibel peter@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
- Next message: Steven E. Harris: "Re: CLOS and C++"
- Previous message: Anthony Ventimiglia: "Re: (sqrt (factorial 100))"
- In reply to: james anderson: "Re: CLOS and C++"
- Next in thread: james anderson: "Re: CLOS and C++"
- Reply: james anderson: "Re: CLOS and C++"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
