Hi,
to whom it interests: I just found the paragraph in the Java Language
Specification where the algorithm for choosing methods by the java
compiler is described:
http://java.sun.com/docs/books/jls/second_edition/html/expressions.doc.html#272863
that does not explain, the individual values, but I guess it helps to
understand what is happening. Maybe we should add a remark to the JLS in
the comments?
Regards
Benedikt
Am 31.01.2012 14:00, schrieb b...@systemoutprintln.de:
Hi Simo,
I liked it to have a the interface name as a prefix. But your're right, it's a
violation of KISS. I'll create a patch this evening.
Thanks again to Matt!
Have a nice day, guys ;-)
Benedikt
----- Original Message -----
From: simonetrip...@apache.org
To: dev@commons.apache.org
Date: 31.01.2012 12:15:51
Subject: Re: [SANDBOX][BeanUtils2] About magic numbers in
AccessibleObjectsRegistry.MethodsRegistry.getObjectTransformationCost(Class
srcClass, Class destClass)...
Hi Benedikt,
why do you have the need of declaring constants in a separate
interface? Isn't the class itself, where they are used, enough?
KISS (keep it simple and straightforward)
-Simo
PS @Matt: thanks a lot once again for the hight valuable feedbacks,
you're a commons-gem!!!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Tue, Jan 31, 2012 at 11:10 AM,<b...@systemoutprintln.de> wrote:
Hey Matt,
thanks for the suggestion! I like the idea of having those numbers encapsulated
in some sort of data structure. But I don't know if an enum fits the purpose.
Maybe I got you wrong. Can you give a code snippet? Defining an enum for float
values would require to implement a private float field on that enum and a
constructor. For example:
private static enum TransformatioCosts {
WRAPPER(0.25f),
INTERFACE(0.25f),
SUPERCLASS(1.0f),
NON_FOUND(1.5f);
private final float value;
TransformationCosts(float value){
this.value = value;
}
}
Reading out the values would look like:
[...]
costs += TransformationCosts.WRAPPER.value;
[...]
I would rather go for an Interface that defines the numbers as constants:
private interface TransformationCosts {
public static final WRAPPER = 0.25f;
public static final INTERFACE = 0.25f;
public static final SUPERCLASS = 1.0f;
public static final NON_FOUND = 1.5f;
}
where the call would look like:
[...]
costs += TransformationCosts.WRAPPER;
[...]
What do you think?
Regards
Benedikt
----- Original Message -----
From: gudnabr...@gmail.com
To: dev@commons.apache.org
Date: 30.01.2012 23:42:06
Subject: Re: [SANDBOX][BeanUtils2] About magic numbers in
AccessibleObjectsRegistry.MethodsRegistry.getObjectTransformationCost(Class
srcClass, Class destClass)...
If we're just talking about a nice way to deal with these magic
numbers perhaps an enumeration would be a nice way to couple each
number with a mnemonic description of its intended use? Thus multiple
enum members could return the weight 0.25f, for example.
Matt
On Mon, Jan 30, 2012 at 4:40 PM, Matt Benson<gudnabr...@gmail.com> wrote:
On Mon, Jan 30, 2012 at 4:36 PM, Benedikt Ritter
<b...@systemoutprintln.de> wrote:
Am 30.01.2012 23:21, schrieb Matt Benson:
Guys, if I know which magic numbers you are discussing, I believe they
are intended to allow a "weight" to be assigned to the action of
calling a given method(or constructor) with a given set of parameters:
the smaller the weight, the more directly assignable the parameters
are to the method being tested. We can thus determine, among several
potential matching signatures, which matches the most closely and
therefore which we expect the compiler would have decided was meant by
an equivalent call made from actual source code. My apologies if I've
completely missed the point of the discussion as I've only been
following loosely.
Hey Matt,
that's exactly what we were talking about! Thank you very much. Do you know
where the penalties that make up the "weights" come from?
I don't know exactly. I would imagine that they were just made up as
a set of numbers that would behave in the way the original contributor
wanted. Perusing the JLS might bear fruit (but then again it might
not). :)
Matt
Looking at
BeanUtils1 MethodUtils.getObjectTransformationCost() I can see that:
* having to wrap a primitive costs 0.25f
* having an interface match costs 0.25f
* having to go one step higher in the class hierarchy costs 1.0f
* having no match in the complete hierarchy costs 1.5f
Are those values extracted from the java spec/the java compiler itself?
Having that information documented in the code would be off great value, if
for what ever reason the implementation has to change some day.
good night,
Benedikt
HTH,
Matt
On Mon, Jan 30, 2012 at 4:14 PM, Benedikt Ritter
<b...@systemoutprintln.de> wrote:
Am 30.01.2012 20:50, schrieb Simone Tripodi:
Sadly nothing is mentioned about the said magic numbers. So we are at
the
start again. Any ideas, how to handle this issue? :)
which issue? is there any weird behavior introduced by the procedure?
No, everything seems to work properly. But I don't understand it and that
bugs me ;-)
anyway, we don't have any chance to understand where/how they come
from, so just extract them as constants, it that has worked from '04
will continue doing it, unless a bug surprisingly comes up.
okay, you will see a patch for that sometime in the next days.
buona notte,
Benedikt
TIA,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
