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? 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

Reply via email to