Tim Ellison wrote:
Geir Magnusson Jr wrote:
Tim Ellison wrote:
Loenko, Mikhail Y wrote:
I agree it is good practice to document the implementation of some
non-API code for developers.
Some? why not all?
... because by definition the non-API code does not require
documentation for the u
Hi Loenko.
On Fri, 2006-01-13 at 15:32 +0300, Loenko, Mikhail Y wrote:
> I think Classpath is a little bit different story. It is not a Java(tm)
> so a developer who writes for Classpath has to validate with Classpath
> docs whether his code is going to work.
No, the goal is to be a free compatib
Hi,
On Fri, 2006-01-13 at 10:38 +, Tim Ellison wrote:
> Perhaps our friends involved with Classpath can give us an insight as to
> whether they regret writing JavaDoc, or whether they see it as a
> valuable part of the effort (assuming that they have written all the doc!).
You can see what we
Geir Magnusson Jr wrote:
>
> Tim Ellison wrote:
>
>> Loenko, Mikhail Y wrote:
>> I agree it is good practice to document the implementation of some
>> non-API code for developers.
>
> Some? why not all?
... because by definition the non-API code does not require
documentation for the user. Wh
> "Mikhail" == Loenko, Mikhail Y <[EMAIL PROTECTED]> writes:
Mikhail> I think Classpath is a little bit different story. It is not
Mikhail> a Java(tm) so a developer who writes for Classpath has to
Mikhail> validate with Classpath docs whether his code is going to
Mikhail> work.
The real reas
Tim Ellison wrote:
Loenko, Mikhail Y wrote:
Well, I'll try to summarize what we have
There are three types of methods:
1. Methods that are part of the API, they are specified, they follow the
Sun's spec and we have nothing to add.
2. Methods that are part of the API and we have something to
Loenko, Mikhail Y wrote:
Well, I'll try to summarize what we have
There are three types of methods:
1. Methods that are part of the API, they are specified, they follow the
Sun's spec and we have nothing to add.
2. Methods that are part of the API and we have something to add (ex.:
the spec al
-dev@incubator.apache.org
>Subject: Re: Writing JavaDoc
>
>Loenko, Mikhail Y wrote:
>> Well, I'll try to summarize what we have
>>
>> There are three types of methods:
>> 1. Methods that are part of the API, they are specified, they follow
the
>> Sun's
methods that act exactly as specified?
My view is that we document them using our own words, and go for quality
documentation as well as quality implementation.
Regards,
Tim
>>-----Original Message-
>>From: Tim Ellison [mailto:[EMAIL PROTECTED]
>>Sent: Tuesday, January 10,
he methods that act exactly as specified?
Thanks,
Mikhail Loenko
Intel Middleware Products Division
>-Original Message-
>From: Tim Ellison [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, January 10, 2006 7:21 PM
>To: harmony-dev@incubator.apache.org
>Subject: Re: Writing JavaDoc
Stefano Mazzocchi wrote:
> Dalibor Topic wrote:
>
>> Zsejki Sorin Miklós wrote:
>>
>>> I have absolutely no experience with such things, but I'm wondering how
>>> was this done with Tomcat, for example. They have the servlet API built
>>> from their source code, and the javadoc seems to be word by
Dalibor Topic wrote:
Zsejki Sorin Miklós wrote:
I have absolutely no experience with such things, but I'm wondering how
was this done with Tomcat, for example. They have the servlet API built
from their source code, and the javadoc seems to be word by word
identical to the specification. Is the
inline
> -Original Message-
> From: Tim Ellison [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, January 10, 2006 5:26 AM
> To: harmony-dev@incubator.apache.org
> Subject: Writing JavaDoc (was: Re: [RESULT] ( Was Re: [VOTE]
> Accept JIRA contribution HARMONY-16 (Intel's contrib of
> security
Tim Ellison wrote:
> Sorry, I misunderstood. So your option #3 is not copying the JavaDoc
> and redistributing it, but documenting links to the Sun site.
>
> IMHO, creating a set of JavaDoc that contains links to Sun's existing
> JavaDoc is unlikely to appeal to most people -- the package/type/me
Zsejki Sorin Miklós wrote:
> I have absolutely no experience with such things, but I'm wondering how
> was this done with Tomcat, for example. They have the servlet API built
> from their source code, and the javadoc seems to be word by word
> identical to the specification. Is the servlet specific
Sorry, I misunderstood. So your option #3 is not copying the JavaDoc
and redistributing it, but documenting links to the Sun site.
IMHO, creating a set of JavaDoc that contains links to Sun's existing
JavaDoc is unlikely to appeal to most people -- the package/type/method
naming is enough of an i
I have absolutely no experience with such things, but I'm wondering how
was this done with Tomcat, for example. They have the servlet API built
from their source code, and the javadoc seems to be word by word
identical to the specification. Is the servlet specification provided
under different
Agreed with #1
Let me better explain #3. It is not a taglet copying Sun's spec. Instead
it should insert pointers to specification of actual methods on Sun's
website. So the resulting docs would look like the following:
public Foo(type arg)
Spec reference: See corresponding J2SE API
spec
18 matches
Mail list logo
