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 Wed, 01 Feb 2012 22:02:13 GMT
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 bene@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: simonetripodi@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,<bene@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: gudnabrsam@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<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
>>>
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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