commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@gmail.com>
Subject Re: [SANDBOX][BeanUtils2] About magic numbers in AccessibleObjectsRegistry.MethodsRegistry.getObjectTransformationCost(Class srcClass, Class destClass)...
Date Mon, 30 Jan 2012 22:42:06 GMT
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 <gudnabrsam@gmail.com> wrote:
> On Mon, Jan 30, 2012 at 4:36 PM, Benedikt Ritter
> <bene@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
>>> <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
>>

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


Mime
View raw message