First class developer: who ?
in [Java Help]
|
Prev: Speaking of thread safety?
Next: solutions manual to A First Course In Probability 7th Edition by Sheldon M. Ross
From: Arne Vajhøj on 14 Mar 2010 15:54 On 13-03-2010 07:46, Arved Sandstrom wrote: > Arne Vajhøj wrote: >> On 12-03-2010 21:08, Arved Sandstrom wrote: >>> Arne Vajhøj wrote: >>>> On 12-03-2010 05:26, Arved Sandstrom wrote: >>>>> Both terms actually have clear English meanings - "equality" means (or >>>>> should mean) that two things *are* the same, and "equivalence" >>>>> means (or >>>>> should mean) that two things can be substituted, that they behave the >>>>> same way. >>>>> >>>>> A mathematical and CS definition in fact tracks the common English >>>>> meanings of these 2 words, and the language concerning Object.equals >>>>> that Patricia quoted does say exactly this: equals is an >>>>> implementation >>>>> of equivalence. >>>>> >>>>> My point is that the common English, the mathematical and the CS >>>>> definitions of the two terms are pretty much the same. And programming >>>>> languages that differentiate between the two also track those >>>>> definitions. We see that Java does. >>>> >>>> I don't think Java follow those rules. >>>> >>>> I assume that you consider equals to be equivalence and >>>> == to be equality. >>>> >>>> But it is not so. >>>> >>>> Example: >>>> >>>> public class ZZ { >>>> public static void main(String[] args) { >>>> int iv = 2; >>>> double xv = 2.0; >>>> System.out.println(iv == xv); >>>> } >>>> } >>> >>> I do consider == to be equality (identity). Same object for references, >>> same value for primitives...that's equality. >> >> But 2 and 2.0 are not identity equals. > > No, but as I indicate I don't see that we ever compared 2 and 2.0 for > identity in your example. You can't do that with direct use of ==, > because of promotion. > > This is one of the C-based hiccups of Java. For primitives of different > types we shouldn't even be asking the question ==? > >>> An implementation of equals() I consider to be _an_ implementation of an >>> equivalence relation; == is clearly another. >>> >>> I'm not that perturbed by your example. Java == equality for primitives >>> of different types is what we define it to be, so defining it to be an >>> operation that takes place after primitive conversions is not wrong. In >>> effect we're not saying that (int 2) == (double 2.0), we're saying that >>> (double 2.0) == (double 2.0); the binary numeric promotion happened >>> before the ==. >> >> That promotion is done by ==. > > "Done by?" I don't see that. "Done on behalf of", sure. Unless a > bytecode guru tells me otherwise I expect that == just like + is > blissfully unaware that it could ever be asked to work with two > primitives of differing types. > > Now, if each binary operator duplicates all the numeric promotion logic > I could see that they are responsible for it. The expression is iv == xv. Everything in that expression is about ==. The promotion is part of what the Java language describe for that operator. == is not testing for identity equals between the two operands for simple types. The fact that it is doing testing for identity equals as part of what it does does not matter because it is not doing it on the two operands. Arne
From: Arne Vajhøj on 14 Mar 2010 16:26 On 14-03-2010 13:03, Martin Gregorie wrote: > On Sun, 14 Mar 2010 09:00:47 -0700, BGB / cr88192 wrote: >> "Martin Gregorie"<martin(a)address-in-sig.invalid> wrote in message >>> IMO, an essential part of the design is making it testable. That should >>> have equal priority with usability, adequate error and incident >>> reporting and a way to measure performance. All are essential to >>> developing a good application. I seldom use a debugger, preferring to >>> use the trace log approach to debugging& testing. I make sure the >>> tracing and its detail levels are easily controlled and invariably >>> leave this code in the product. The performance hit is almost >>> undetectable when its turned off and the payoff from being able to turn >>> it on during a production run is huge. >> I use a debugger some amount, usually to identify where a problem has >> occured and the situation at the place it has occured. >> > I've usually found debuggers to be the slower option in terms of > programmer time. Tracing statements that show data as well as location > are a better way of tracking down the problem - especially when the > causative code is some distance from the apparent trouble spot. Not to mention that quite often the problem does not happen when debugging. Concurrency problems are frequent problems. Often debugging requires optimization turned off and then bad code may work. Etc.. In server programming debuggers are mostly a tool to impress pointy haired bosses with. They are OK for many desktop apps. Arne
From: Arne Vajhøj on 14 Mar 2010 16:28 On 14-03-2010 13:03, Martin Gregorie wrote: > On Sun, 14 Mar 2010 09:00:47 -0700, BGB / cr88192 wrote: >> "Martin Gregorie"<martin(a)address-in-sig.invalid> wrote in message >>> IMO, an essential part of the design is making it testable. That should >>> have equal priority with usability, adequate error and incident >>> reporting and a way to measure performance. All are essential to >>> developing a good application. I seldom use a debugger, preferring to >>> use the trace log approach to debugging& testing. I make sure the >>> tracing and its detail levels are easily controlled and invariably >>> leave this code in the product. The performance hit is almost >>> undetectable when its turned off and the payoff from being able to turn >>> it on during a production run is huge. >> I use a debugger some amount, usually to identify where a problem has >> occured and the situation at the place it has occured. >> > I've usually found debuggers to be the slower option in terms of > programmer time. Tracing statements that show data as well as location > are a better way of tracking down the problem - especially when the > causative code is some distance from the apparent trouble spot. Not to mention that quite often the problem does not happen when debugging. Concurrency problems are frequent problems. Often debugging requires optimization turned off and then bad code may work. Etc.. In server programming debuggers are mostly a tool to impress pointy haired bosses with. They are OK for many desktop apps. Arne
From: Arved Sandstrom on 14 Mar 2010 17:25 Arne Vajhøj wrote: > On 13-03-2010 07:46, Arved Sandstrom wrote: >> Arne Vajhøj wrote: >>> On 12-03-2010 21:08, Arved Sandstrom wrote: >>>> Arne Vajhøj wrote: >>>>> On 12-03-2010 05:26, Arved Sandstrom wrote: >>>>>> Both terms actually have clear English meanings - "equality" means >>>>>> (or >>>>>> should mean) that two things *are* the same, and "equivalence" >>>>>> means (or >>>>>> should mean) that two things can be substituted, that they behave the >>>>>> same way. >>>>>> >>>>>> A mathematical and CS definition in fact tracks the common English >>>>>> meanings of these 2 words, and the language concerning Object.equals >>>>>> that Patricia quoted does say exactly this: equals is an >>>>>> implementation >>>>>> of equivalence. >>>>>> >>>>>> My point is that the common English, the mathematical and the CS >>>>>> definitions of the two terms are pretty much the same. And >>>>>> programming >>>>>> languages that differentiate between the two also track those >>>>>> definitions. We see that Java does. >>>>> >>>>> I don't think Java follow those rules. >>>>> >>>>> I assume that you consider equals to be equivalence and >>>>> == to be equality. >>>>> >>>>> But it is not so. >>>>> >>>>> Example: >>>>> >>>>> public class ZZ { >>>>> public static void main(String[] args) { >>>>> int iv = 2; >>>>> double xv = 2.0; >>>>> System.out.println(iv == xv); >>>>> } >>>>> } >>>> >>>> I do consider == to be equality (identity). Same object for references, >>>> same value for primitives...that's equality. >>> >>> But 2 and 2.0 are not identity equals. >> >> No, but as I indicate I don't see that we ever compared 2 and 2.0 for >> identity in your example. You can't do that with direct use of ==, >> because of promotion. >> >> This is one of the C-based hiccups of Java. For primitives of different >> types we shouldn't even be asking the question ==? >> >>>> An implementation of equals() I consider to be _an_ implementation >>>> of an >>>> equivalence relation; == is clearly another. >>>> >>>> I'm not that perturbed by your example. Java == equality for primitives >>>> of different types is what we define it to be, so defining it to be an >>>> operation that takes place after primitive conversions is not wrong. In >>>> effect we're not saying that (int 2) == (double 2.0), we're saying that >>>> (double 2.0) == (double 2.0); the binary numeric promotion happened >>>> before the ==. >>> >>> That promotion is done by ==. >> >> "Done by?" I don't see that. "Done on behalf of", sure. Unless a >> bytecode guru tells me otherwise I expect that == just like + is >> blissfully unaware that it could ever be asked to work with two >> primitives of differing types. >> >> Now, if each binary operator duplicates all the numeric promotion logic >> I could see that they are responsible for it. > > The expression is iv == xv. Everything in that expression is about ==. > > The promotion is part of what the Java language describe for > that operator. > > == is not testing for identity equals between the two operands for > simple types. > > The fact that it is doing testing for identity equals as part > of what it does does not matter because it is not doing it > on the two operands. > > Arne If I parse what you just now said accurately, you're agreeing with me: in this example == is not comparing 2 and 2.0. AHS
From: Arne Vajhøj on 14 Mar 2010 19:09
On 14-03-2010 17:25, Arved Sandstrom wrote: > Arne Vajhøj wrote: >> On 13-03-2010 07:46, Arved Sandstrom wrote: >>> Arne Vajhøj wrote: >>>> On 12-03-2010 21:08, Arved Sandstrom wrote: >>>>> Arne Vajhøj wrote: >>>>>> On 12-03-2010 05:26, Arved Sandstrom wrote: >>>>>>> Both terms actually have clear English meanings - "equality" >>>>>>> means (or >>>>>>> should mean) that two things *are* the same, and "equivalence" >>>>>>> means (or >>>>>>> should mean) that two things can be substituted, that they behave >>>>>>> the >>>>>>> same way. >>>>>>> >>>>>>> A mathematical and CS definition in fact tracks the common English >>>>>>> meanings of these 2 words, and the language concerning Object.equals >>>>>>> that Patricia quoted does say exactly this: equals is an >>>>>>> implementation >>>>>>> of equivalence. >>>>>>> >>>>>>> My point is that the common English, the mathematical and the CS >>>>>>> definitions of the two terms are pretty much the same. And >>>>>>> programming >>>>>>> languages that differentiate between the two also track those >>>>>>> definitions. We see that Java does. >>>>>> >>>>>> I don't think Java follow those rules. >>>>>> >>>>>> I assume that you consider equals to be equivalence and >>>>>> == to be equality. >>>>>> >>>>>> But it is not so. >>>>>> >>>>>> Example: >>>>>> >>>>>> public class ZZ { >>>>>> public static void main(String[] args) { >>>>>> int iv = 2; >>>>>> double xv = 2.0; >>>>>> System.out.println(iv == xv); >>>>>> } >>>>>> } >>>>> >>>>> I do consider == to be equality (identity). Same object for >>>>> references, >>>>> same value for primitives...that's equality. >>>> >>>> But 2 and 2.0 are not identity equals. >>> >>> No, but as I indicate I don't see that we ever compared 2 and 2.0 for >>> identity in your example. You can't do that with direct use of ==, >>> because of promotion. >>> >>> This is one of the C-based hiccups of Java. For primitives of different >>> types we shouldn't even be asking the question ==? >>> >>>>> An implementation of equals() I consider to be _an_ implementation >>>>> of an >>>>> equivalence relation; == is clearly another. >>>>> >>>>> I'm not that perturbed by your example. Java == equality for >>>>> primitives >>>>> of different types is what we define it to be, so defining it to be an >>>>> operation that takes place after primitive conversions is not >>>>> wrong. In >>>>> effect we're not saying that (int 2) == (double 2.0), we're saying >>>>> that >>>>> (double 2.0) == (double 2.0); the binary numeric promotion happened >>>>> before the ==. >>>> >>>> That promotion is done by ==. >>> >>> "Done by?" I don't see that. "Done on behalf of", sure. Unless a >>> bytecode guru tells me otherwise I expect that == just like + is >>> blissfully unaware that it could ever be asked to work with two >>> primitives of differing types. >>> >>> Now, if each binary operator duplicates all the numeric promotion logic >>> I could see that they are responsible for it. >> >> The expression is iv == xv. Everything in that expression is about ==. >> >> The promotion is part of what the Java language describe for >> that operator. >> >> == is not testing for identity equals between the two operands for >> simple types. >> >> The fact that it is doing testing for identity equals as part >> of what it does does not matter because it is not doing it >> on the two operands. >> Arne > > If I parse what you just now said accurately, you're agreeing with me: > in this example == is not comparing 2 and 2.0. It is. At the Java language level it is comparing those two. That comparison consists of a promotion and an identity equality test between one of the variables and a temporary variable. Arne |