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: simonetrip...@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, <b...@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: gudnabr...@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 <gudnabr...@gmail.com> wrote: >>>> On Mon, Jan 30, 2012 at 4:36 PM, Benedikt Ritter >>>> <b...@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 >>>>>> <b...@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-unsubscr...@commons.apache.org >>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >> >> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
