Whatever way you put it, any subtyping relationship between primitives is going to violate the Liskov Substitution Principle. And so should be considered evil.
Implicit conversions, however, are perfectly acceptable :) On 6 Dec 2010 16:47, "Alexey Zinger" <[email protected]> wrote: > A few corrections are in order. I think you got the primitive type hierarchy > backwards: "double extends float" should read "float extends double", both > according to the link and if you think about which way loss of precision > occurs. To be fair, I think it's wrong to talk about type hierarchy with > primitives. By definition, they fall outside the traditional object model and > behave as an approximation of characteristics of chips and memory and so on. > With primitives, we talk about precision, type size and other low-level > concepts. Casting of primitive types, a la (long)5 is an entirely different > operation that casting of reference types. It's actually type conversion. > True, sometimes it happens implicitly, which can generally happen along the > "hierarchy" outlined, but really, it's not at all the same as implicitly casting > String to Object. > > So it may be confusing to have some type hierarchy in wrapper classes that > extend Number that's totally different that implicit casts and direction of > precision loss in primitives, but it isn't wrong. The source of confusion here > is that we're straddling object- and non-object worlds. Their memory allocation > is different. They're passed around the stack differently. Garbage collection > is different. Type conversion is different. You could stipulate that Java > should have had primitive support on the bytecode level without exposing them in > Java-the-language. And you could say it was important for certain library > authors to have that exposure, due to lack of other languages on the JVM at the > early stages. But whatever the case, in terms of legacy support, we have what > we have in Java and the JVM, and we now have "purer" object models in some other > JVM languages and if we want to work in Java, we just need to be aware of the > quirks of the type system. We've always known that. > > Alexey > > > > > > ________________________________ > From: Reinier Zwitserloot <[email protected]> > To: The Java Posse <[email protected]> > Sent: Sun, December 5, 2010 8:51:14 AM > Subject: [The Java Posse] Re: James Gosling on Apple, Apache, Google, Oracle and > the Future of Java > > If you want to blame somebody / some decision here, blame the notion > that primitives have different typing relationships than their boxed > equivalents. That's the primary issue stopping any attempt to make > primitives less 'special'. > > According to the JLS: > http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.10.1 > > double extends float extends long extends int extends short extends > byte. And while we're at it, int also extends char, and boolean is in > its own little world. > > Double, Float, Integer, Short, Byte, Character, and Long, on the other > hand, all extend Number, and have no sub/supertype relations amongst > themselves at all. > > This is a great source of puzzlers and the main argument Neal Gafter > uses to counter any talk of for example getting rid of primitives > altogether, or even allowing primitives in generics. In case you don't > see the relevance: Sub/supertype relations are important when > resolving methods. If you see: > > foo(5) > > and there's a foo method: > > void foo(double in) {} > > then the reason it'll get called is because 5 (being of the 'int' > type) is an instance of double (after all, 'int' is a subtype of > double. This is no different from an instance of ArrayList being > appropriate to pass as parameter to a method that takes List). But in > wrapper world, this doesn't work: > > foo(new Integer(5)); > > and with foo method: > > void foo(Double in) {} > > now the compiler won't compile it, complaining that 'Integer' cannot > be applied to 'Double', because while int is a subtype of double, > Integer is NOT a subtype of Double. If you start mixing primitives and > their wrappers, autoboxing comes into play and then nobody knows what > happens anymore. > > Note that method resolution is 100% a java-the-language thing. The JVM > has no resolution at all; each method call is explicitly defined with > complete information: full location (package + class), method name, > and full type of all parameters and the return type. i.e. > Integer.parseInt is in JVM speak: "java/lang/Integer parseInt (Ljava/ > lang/String;)I". There is no super/subtyping at all; if the method > signature doesn't match exactly, you get a MethodNotFoundError. > There's also no autoboxing, that was also a purely java-the-language > invention. Which does go to show that you can make primitives more > usable with a purely language-based change. > > If these subtyping relations had never been written (i.e. double was > never defined as being a superclass of float, for example), then > changing java-the-language to effectively get rid of primitives > altogether, with javac smart enough to optimize code and generate > primitives at the JVM level, would have been a heck of a lot simpler. > Alternatively blame the guys who designed java.lang.Integer and > friends. While strange, they could have mirrored these relationships > and declared java.lang.Integer to extend java.lang.Double, and so on. > Of course, fixing _that_ would be backwards incompatible. D'oh! > > *) Actually, my personal opinion on this runs counter to the concepts > above: It's already a cesspool no java developer but geeks like me who > read the JLS front-to-back understand. That'll never get better, so > might as well roll with it and come up with an even more convoluted > fix. Getting rid of primitives is worth making an already complicated > mess even more complicated. But this is one of those areas where I > haven't yet managed to convince the JLS brass (Reinhold, Goetz, > Buckley, and friends) yet that Neal's arguments get trumped by > practicality. Who knows, though - BGGA went down in flames in favour > of SAM-based closures... which incidentally vastly increase the > importance of at least allowing primitives in generics (so that you > can write a Comparator<int>, for example, which you could then use to > sort an int[], which is not currently possible in java without writing > your own method to do it!). Who knows what'll happen as Project Lambda > develops? > > > On Dec 4, 8:01 pm, Cédric Beust ♔ <[email protected]> wrote: >> On Sat, Dec 4, 2010 at 7:28 AM, Neil Bartlett <[email protected]> wrote: >> > I'm *not* surprised that he didn't mention the Date and Calendar APIs. >> > He should have, but I'm not surprised he didn't. I'm also not >> > surprised that he failed to mention primitives and arrays. >> >> Careful with revisionism here. >> >> I think the decision to have primitives is one of the subtle details that >> made Java the success it is today. Back then, performance was a huge deal >> and it took years before Java's speed started being perceived as "good >> enough". With that in mind, using objects for everything would have been a >> terrible mistake, one that might have turned Java into an interesting >> language that was soon sent back to the dark corners of programming language >> history. >> >> It's always dangerous to reexamine past decisions with present insight. >> >> A more interesting hypothetical question to me is what language would have >> emerged if Java hadn't succeeded... >> >> -- >> Cédric > > -- > You received this message because you are subscribed to the Google Groups "The > Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<javaposse%[email protected]> . > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > > > > -- > You received this message because you are subscribed to the Google Groups "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to [email protected]<javaposse%[email protected]> . > For more options, visit this group at http://groups.google.com/group/javaposse?hl=en. > -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
