commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benedikt Ritter <b...@systemoutprintln.de>
Subject Re: [SANDBOX][BeanUtils2] About magic numbers in AccessibleObjectsRegistry.MethodsRegistry.getObjectTransformationCost(Class srcClass, Class destClass)...
Date Mon, 30 Jan 2012 22:36:52 GMT
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
> <bene@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-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message