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
