I believe extends in the prev post was about widening from int to long etc it was not about equal substitution aka Liskov s/p.
On 07/12/2010, at 4:41 AM, Kevin Wright <[email protected]> wrote: > 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]. > > 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. > > > -- > 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. -- 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.
