Also, the compiler is probably more accurate at keeping inherited
documentation up to date.
On Sun, Jul 24, 2011 at 10:52 PM, Jörg Schaible joerg.schai...@scalaris.com
wrote:
Right, and including it creates a placeholder to expand on or modify
the inherited javadoc. I think we should keep
hi all guys,
I thought that moving from jakarta to commons community was enough to
justify a binary compatibility breakage.
have a nice day!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Sun, Jul 24, 2011 at 4:36 PM, Jörg Schaible joerg.schai...@gmx.de wrote:
sebb
Hi Phil,
Phil Steitz wrote:
On 7/24/11 10:52 PM, Jörg Schaible wrote:
Hi Phil,
Phil Steitz wrote:
On 7/24/11 3:13 PM, Gilles Sadowski wrote:
Hello.
I saw in the sources serveral /** {@inheritDoc} */ on methods with
@Override annotation. Javadoc knows to inherit the javadoc of the
- Mail original -
De: Gilles Sadowski gil...@harfang.homelinux.org
À: dev@commons.apache.org
Envoyé: Lundi 25 Juillet 2011 00:18:56
Objet: Re: [jira] [Resolved] (MATH-599) Re-implementation of Secant-based root
finding algorithms
Luc Maisonobe resolved MATH-599.
Here's the problem as I see it. Code with no javadoc is bad, bad,
bad.
Good code needs little javadocs.
http://vafer.org/blog/20050323095453/
Good docs and good code over noise - any time.
cheers,
Torsten
-
To
Hi all,
some components keep the Javadocs for older versions online in addition
to the ones of the current release. In our case the Javadocs for 1.2
won't be too different from the ones of 1.1, so I don't think it is
worthwhile, but still I'd like to double check.
Does anybody want the Javadocs
Hi Jörg,
- Mail original -
De: Jörg Schaible joerg.schai...@scalaris.com
À: dev@commons.apache.org
Envoyé: Lundi 25 Juillet 2011 09:19:36
Objet: Re: [math] Inherits doc and @Override
Hi Phil,
Phil Steitz wrote:
On 7/24/11 10:52 PM, Jörg Schaible wrote:
Hi Phil,
Phil Steitz wrote:
Hi Stefan!!!
I think that keeping old javadocs would have more sense when we
release major releases, for cases such as compress 1.1 - 1.2, tags
like @since, @deprecated, ... are more than enough.
just my 2 cents, have a nice day!!!
Simo
http://people.apache.org/~simonetripodi/
Hi all,
given that most discussion has only been started late last week, it has
been a bit unorganized and some things have moved during the weekend
I'll give it a bit more time to settle.
IMHO svn trunk is ready to be released and likely won't change except
for release notes, version numbers
Hi Stefan,
- Mail original -
Hi all,
some components keep the Javadocs for older versions online in
addition
to the ones of the current release. In our case the Javadocs for 1.2
won't be too different from the ones of 1.1, so I don't think it is
worthwhile, but still I'd like to
- Mail original -
Hello.
Hi Gilles,
Finding myself repeatedly writing the same few lines when trying to
figure
out which of several implementations of some functionality was
running
faster, I wonder wether it would be interesting to add a little
utility in
the test section of
On 2011-07-25, luc.maison...@free.fr wrote:
If the URL do include the version, then it would be better to keep old
version online, to avoid dangling links from external web pages, mail
archives or documentation.
Good point, thanks Luc. The Javadoc URLs for Compress currently don't
contain a
On 23.07.11 08:17, Henri Yandell wrote:
If you want to get the code committed, it makes life fractionally
easier for you rather than figuring out how to svn switch over. I'm
happy to wait on your nod before doing the svn move.
It's ok as it is now.
How is the policy here concerning larger
On 25 July 2011 09:13, Torsten Curdt tcu...@vafer.org wrote:
Here's the problem as I see it. Code with no javadoc is bad, bad,
bad.
+1
Good code needs little javadocs.
I disagree strongly.
The Javadoc should present the public API (and should ideally be
written before the code - i.e. the
Good code needs little javadocs.
I disagree strongly.
The Javadoc should present the public API (and should ideally be
written before the code - i.e. the code implements the docs).
If the only documentation is the code, it is much harder for users to
determine how to use the API.
For
On 2011-07-21, sebb wrote:
However just doing that without adding @Override and minimal generics
will result in compilation warnings; it seems wromg to release source
that does not compile cleanly.
The zip64 branch now requires Java5 but I'm having a hard time seeing
any compiler warnings.
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-proxy-test has an issue affecting its community integration.
This
On Mon, Jul 25, 2011 at 5:07 AM, Torsten Curdt tcu...@vafer.org wrote:
Good code needs little javadocs.
I disagree strongly.
The Javadoc should present the public API (and should ideally be
written before the code - i.e. the code implements the docs).
If the only documentation is the code,
I am not saying don't use javadocs. It's all about using javadocs effectively.
Forcing javadocs on all methods leads to bloat and noise. Better
present stellar javadocs on public APIs and document how the library
works. Having great examples helps a great deal ...but don't (please
don't!) use
2011/7/22 Arne Ploese aplo...@gmx.de:
Hi,
I saw in the sources serveral /** {@inheritDoc} */ on methods with
@Override annotation. Javadoc knows to inherit the javadoc of the
overwritten methos, so there is no need for @inheritDoc.
If all agree, one could drop this if the code is modified?
On 7/25/11 1:13 AM, Torsten Curdt wrote:
Here's the problem as I see it. Code with no javadoc is bad, bad,
bad.
Good code needs little javadocs.
http://vafer.org/blog/20050323095453/
Good docs and good code over noise - any time.
Ummno.
Without method javadoc, library code is
On 7/25/11 1:36 AM, luc.maison...@free.fr wrote:
Hi Jörg,
- Mail original -
De: Jörg Schaible joerg.schai...@scalaris.com
À: dev@commons.apache.org
Envoyé: Lundi 25 Juillet 2011 09:19:36
Objet: Re: [math] Inherits doc and @Override
Hi Phil,
Phil Steitz wrote:
On 7/24/11 10:52
On Mon, Jul 25, 2011 at 9:59 AM, Phil Steitz phil.ste...@gmail.com wrote:
On 7/25/11 1:36 AM, luc.maison...@free.fr wrote:
Hi Jörg,
- Mail original -
De: Jörg Schaible joerg.schai...@scalaris.com
À: dev@commons.apache.org
Envoyé: Lundi 25 Juillet 2011 09:19:36
Objet: Re: [math]
On 7/25/11 6:55 AM, Torsten Curdt wrote:
I am not saying don't use javadocs. It's all about using javadocs effectively.
Forcing javadocs on all methods leads to bloat and noise. Better
present stellar javadocs on public APIs and document how the library
works. Having great examples helps a
On Mon, Jul 25, 2011 at 4:41 AM, Stefan Bodewig bode...@apache.org wrote:
Hi all,
given that most discussion has only been started late last week, it has
been a bit unorganized and some things have moved during the weekend
I'll give it a bit more time to settle.
IMHO svn trunk is ready to
On 7/25/11 6:31 AM, Matt Benson wrote:
On Mon, Jul 25, 2011 at 5:07 AM, Torsten Curdt tcu...@vafer.org wrote:
Good code needs little javadocs.
I disagree strongly.
The Javadoc should present the public API (and should ideally be
written before the code - i.e. the code implements the docs).
Maybe I am working too much in other languages to appreciate the less
is more way of coding.
Self descriptive code is less a myth but more a state of mind when
writing that code and documentation.
The problem with that state of mind is that unless and until you
clearly specify a contract
On 7/25/11 8:27 AM, Torsten Curdt wrote:
Maybe I am working too much in other languages to appreciate the less
is more way of coding.
Self descriptive code is less a myth but more a state of mind when
writing that code and documentation.
The problem with that state of mind is that unless and
On Mon, Jul 25, 2011 at 10:27 AM, Torsten Curdt tcu...@vafer.org wrote:
Maybe I am working too much in other languages to appreciate the less
is more way of coding.
Self descriptive code is less a myth but more a state of mind when
writing that code and documentation.
The problem with that
On 25 July 2011 16:23, Gary Gregory ggreg...@apache.org wrote:
On Mon, Jul 25, 2011 at 4:41 AM, Stefan Bodewig bode...@apache.org wrote:
Hi all,
given that most discussion has only been started late last week, it has
been a bit unorganized and some things have moved during the weekend
I'll
Hey all,
OpenSymphony has closed. Not sure if OSCache has survived.
This page recommends OSCache:
http://cayenne.apache.org/doc/query-result-caching.html
It looks like this project is the follow up:
java.net/projects/oscache
But it seems also to be rather dead (last commit 4 yrs)
Is it time
Wrong list? ;)
Matt
On Mon, Jul 25, 2011 at 1:18 PM, Christian Grobmeier
grobme...@gmail.com wrote:
Hey all,
OpenSymphony has closed. Not sure if OSCache has survived.
This page recommends OSCache:
http://cayenne.apache.org/doc/query-result-caching.html
It looks like this project is the
uh yes :-)
Sorry for the spam - time to have dinner and grab a beer!
On Mon, Jul 25, 2011 at 8:29 PM, Matt Benson gudnabr...@gmail.com wrote:
Wrong list? ;)
Matt
On Mon, Jul 25, 2011 at 1:18 PM, Christian Grobmeier
grobme...@gmail.com wrote:
Hey all,
OpenSymphony has closed. Not sure
Dinner? It is only 9am in Hawaii. I haven't even had breakfast yet.
Ralph
On Jul 25, 2011, at 11:30 AM, Christian Grobmeier wrote:
uh yes :-)
Sorry for the spam - time to have dinner and grab a beer!
On Mon, Jul 25, 2011 at 8:29 PM, Matt Benson gudnabr...@gmail.com wrote:
Wrong list?
On Sun, Jul 24, 2011 at 07:27:50PM -0700, Phil Steitz wrote:
On 7/24/11 2:43 PM, er...@apache.org wrote:
Author: erans
Date: Sun Jul 24 21:43:08 2011
New Revision: 1150496
URL: http://svn.apache.org/viewvc?rev=1150496view=rev
Log:
MATH-632
Added tests referred to in the
On Mon, Jul 25, 2011 at 9:56 AM, Stefan Bodewig bode...@apache.org wrote:
On 2011-07-25, luc.maison...@free.fr wrote:
If the URL do include the version, then it would be better to keep old
version online, to avoid dangling links from external web pages, mail
archives or documentation.
Good
Hello.
[...]
The idea is to have interleaved calls to the candidate
implementations, so
that (hopefully) they will be penalized (or benefit) in the same way
by what
the JVM is doing (GC or JIT compilation or ...) while the benchmark
is
running.
Does this make sense?
37 matches
Mail list logo
