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
