It's possible that it might have been described like that for political reasons.
Given some of the concerns I've seen expressed over implicit conversions in Scala (they're often seen as risky "magic"), I can completely understand why Sun would shy away from such a phrase for a language that they wanted to market as being both simple and object oriented. On 6 Dec 2010 22:03, "Alexey Zinger" <[email protected]> wrote: > I can only speak for myself, but after years of exposure to different specs and > reference documents, I was very surprised to see Sun talk about the primitives > that way in the language spec. Seems like a very poor choice of words to > describe implied conversions. I suppose they were already feeling > self-conscious about exposed primitives and wanted to make them "feel" a little > less removed from the object paradigm than they actually are. > > Alexey > > > > > > ________________________________ > From: Kevin Wright <[email protected]> > To: [email protected] > Sent: Mon, December 6, 2010 4:44:11 PM > Subject: Re: [The Java Posse] Re: James Gosling on Apple, Apache, Google, Oracle > and the Future of Java > > Java Language Spec, 3rd Edition, page 63: > > > 4.10.1 Subtyping among Primitive Types > The following rules define the direct supertype relation among the primitive > types: > double > float > float > long > long > int > int > char > int > short > short > byte > > immediately followed by > > "4.10.2 Subtyping among Class and Interface Types" > "4.10.3 Subtyping among Array Types" > > I think it's totally, unarguably clear that subtyping ("extends") is used here > in the very precise sense that it has attained with object-oriented programming. > > So yes, LSP really *does* apply here. It's just another of Java's beloved > "simple" qualities... > > > > On 6 December 2010 21:27, Miroslav Pokorny <[email protected]> wrote: > > 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]<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]<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. >> > > > -- > Kevin Wright > > mail / gtalk / msn : [email protected] > > pulse / skype: kev.lee.wright > twitter: @thecoda > > > -- > 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.
