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
