On 09/25/2015 12:55 PM, Thomas Neidhart wrote:
On 09/25/2015 05:04 PM, Ole Ersoy wrote:
Hi Thomas,
On 09/25/2015 08:45 AM, Thomas Neidhart wrote:
Hi Ole,
can you explain why you think that the addition of lombok brings any
benefit to our users?
Sure - I'm looking at the LevenbergMarquardtOptimizer ATM, and it has
the following set of parameters:
/* configuration parameters */
/** Positive input variable used in determining the initial step
bound. */
private final double initialStepBoundFactor;
/** Desired relative error in the sum of squares. */
private final double costRelativeTolerance;
/** Desired relative error in the approximate solution parameters. */
private final double parRelativeTolerance;
/** Desired max cosine on the orthogonality between the function vector
* and the columns of the jacobian. */
private final double orthoTolerance;
/** Threshold for QR ranking. */
private final double qrRankingThreshold;
And corresponding getters:
/**
* Gets the value of a tuning parameter.
* @see #withInitialStepBoundFactor(double)
*
* @return the parameter's value.
*/
public double getInitialStepBoundFactor() {
return initialStepBoundFactor;
}
/**
* Gets the value of a tuning parameter.
* @see #withCostRelativeTolerance(double)
*
* @return the parameter's value.
*/
public double getCostRelativeTolerance() {
return costRelativeTolerance;
}
/**
* Gets the value of a tuning parameter.
* @see #withParameterRelativeTolerance(double)
*
* @return the parameter's value.
*/
public double getParameterRelativeTolerance() {
return parRelativeTolerance;
}
/**
* Gets the value of a tuning parameter.
* @see #withOrthoTolerance(double)
*
* @return the parameter's value.
*/
public double getOrthoTolerance() {
return orthoTolerance;
}
/**
* Gets the value of a tuning parameter.
* @see #withRankingThreshold(double)
*
* @return the parameter's value.
*/
public double getRankingThreshold() {
return qrRankingThreshold;
}
Lombok will generate all of these. Eclipse can do the same thing, but
if we delete one of the parameters, then the corresponding getter also
has to be deleted. Also Lombok cuts down on the source code noise,
since it is a byte code generator. The generated code does not appear
in the source.
Lombok also has a @Builder annotation that can be used to generate a
inner static builder class that provides a fluent construction API. So
if we break off the LevenbergMarquardtOptimizer configuration into its
own class, and generate all the getters and the fluid API, there should
be substantial code reduction.
Gilles is also working on a snapshot capability for neural nets, and the
@Synchronized annotation could come in handy here. These are the items
I have looked at so far.
>From my point of view, lombok can help developers by taking over some
tedious tasks, but this is quite irrelevant in the case of CM as the
majority of work goes into algorithm design and verification rather
than in
writing getters/setters (which btw has pretty good IDE support).
I agree that the majority of time goes into the design of the
algorithm. For me personally, when I'm looking at code, and it has a
ton of boilerplate, it does slow my productivity...just because of all
the noise. I'm happy once I've gotten it as DRY as possible.
The more boilerplate, the more reluctant we are going to be to undertake
refactoring, and we will make more mistakes (At least I will :) ).
So this
would just add additional complexity and the gain is very unclear.
I think you will find it refreshing once you try it. At this point
though I just wanted to float the idea. I'll complete the experiment
and publish the result. At that point we will have a good baseline to
gage whether adding it will add enough value to offset the cost of
adding it.
Well I know lombok.
Super!
Keep in mind that it is a bit more difficult to integrate it into our
build-chain. As you probably know, in order to generate proper javadoc,
you need to use delombok first to create source files which can be used
for the javadoc process.
I was thinking about that too actually. Here's how I was thinking it could be
done in the case of the LevenbergMarquardtOptimizer. First split the
configuration piece off. Then javadoc the properties of the configuration
only. In the class header explain that the boilerplate has been generated
using Lombok and put a reference to it there. If someone is smart enough to
figure out how to work with the optimizer, then this should be trivial.
So to summarize - move to a process of providing minimal javadoc and zero
boilerplate. Explain to users that Lombok is used to facilitate this, so
methods that are standard boilerplate, do not have comments. Rely on user
documentation and unit test examples to guide users. I think this would be
good because it's less Javadoc noise.
In general I do not think that lombok is the right tool for a library
like CM, and I do not know any other library that uses lombok. It
certainly has strengths and uses for application development though.
Totally respect that. I'll try integrating it with the general CM build
process for the experiment. Maybe I can work out the kinks.
Cheers,
- Ole
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
