You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by be...@systemoutprintln.de on 2012/01/31 11:10:49 UTC
Re: [SANDBOX][BeanUtils2] About magic numbers inAccessibleObjectsRegistry.MethodsRegistry.getObjectTransformationCost(Class srcClass, Class destClass)...
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 <gu...@gmail.com> wrote:
>> On Mon, Jan 30, 2012 at 4:36 PM, Benedikt Ritter
>> <be...@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
>>>> <be...@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
Re: [SANDBOX][BeanUtils2] About magic numbers in AccessibleObjectsRegistry.MethodsRegistry.getObjectTransformationCost(Class
srcClass, Class destClass)...
Posted by Benedikt Ritter <be...@systemoutprintln.de>.
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,<be...@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<gu...@gmail.com> wrote:
>>>>> On Mon, Jan 30, 2012 at 4:36 PM, Benedikt Ritter
>>>>> <be...@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
>>>>>>> <be...@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
Re: [SANDBOX][BeanUtils2] About magic numbers inAccessibleObjectsRegistry.MethodsRegistry.getObjectTransformationCost(Class srcClass, Class destClass)...
Posted by be...@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, <be...@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 <gu...@gmail.com> wrote:
>>>> On Mon, Jan 30, 2012 at 4:36 PM, Benedikt Ritter
>>>> <be...@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
>>>>>> <be...@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
Re: [SANDBOX][BeanUtils2] About magic numbers in AccessibleObjectsRegistry.MethodsRegistry.getObjectTransformationCost(Class
srcClass, Class destClass)...
Posted by Simone Tripodi <si...@apache.org>.
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, <be...@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 <gu...@gmail.com> wrote:
>>> On Mon, Jan 30, 2012 at 4:36 PM, Benedikt Ritter
>>> <be...@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
>>>>> <be...@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