commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From b...@systemoutprintln.de
Subject Re: [SANDBOX][BeanUtils2] About magic numbers in AccessibleObjectsRegistry.MethodsRegistry.getObjectTransformationCost(Class srcClass, Class destClass)...
Date Tue, 31 Jan 2012 13:00:30 GMT
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


Mime
View raw message