Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
In-Reply-To: 
 <CAE9L6G0kSeEBDCvPniMOj=wBrDxPnnivc3Xa+dqjpOSmBEiS4A@mail.gmail.com>
References: <4F26D515.1000008@systemoutprintln.de>
 <CAAqLGLOtcJR_UpQq1yGW2tgR5kR6PHzQ6jBKoa0-ef_OCBGXHA@mail.gmail.com>
 <4F27162E.4050300@systemoutprintln.de>
 <CAE9L6G3+KHJ5425FOG3dSZ+CnLZaxSAG_LW7vNudKp-NtD175Q@mail.gmail.com>
 <4F271B84.5010401@systemoutprintln.de>
 <CAE9L6G1oZGZHc6Jq7vqYMPfMxB4ksQHaJMYY=F_TJXqsHxm_JA@mail.gmail.com>
 <CAE9L6G0kSeEBDCvPniMOj=wBrDxPnnivc3Xa+dqjpOSmBEiS4A@mail.gmail.com>
Subject: Re: [SANDBOX][BeanUtils2] About magic numbers in
	 =?ISO-8859-1?Q?AccessibleObjectsRegistry=2EMethodsRegistry=2EgetObjectTra?=
	 =?ISO-8859-1?Q?nsformationCost=28Class=20srcClass=2C=20Class=20destClass?=
	 =?ISO-8859-1?Q?=29=2E=2E=2E?=
From: bene@systemoutprintln.de
To: dev@commons.apache.org
MIME-Version: 1.0
User-Agent: ALL-INKL Webmail
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Message-Id: <20120131101049.6725B2DA008E@dd25322.kasserver.com>
Date: Tue, 31 Jan 2012 11:10:49 +0100 (CET)

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