commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simonetrip...@apache.org>
Subject Re: [SANDBOX][BeanUtils2] About magic numbers in AccessibleObjectsRegistry.MethodsRegistry.getObjectTransformationCost(Class srcClass, Class destClass)...
Date Tue, 31 Jan 2012 11:15:51 GMT
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


Mime
View raw message