The subtyping relationship between primitives has nothing to do with conversion, and is _exactly_ like 'extends' for object types, at least where method resolution is concerned. Once resolution has figured out which method is intended, then, yes, conversion has to occur, because while an instance of ArrayList will seamlessly operate as a List at the JVM level, a long obviously won't act anything like a double.
But this conversion has no role of any kind for resolution itself - no conversion is done, and legal conversions aren't even considered, when deciding which of a bunch of overloaded methods is intended for any given call. On Dec 6, 11:11 pm, Kevin Wright <[email protected]> wrote: > 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.htm... > > > > > > > > > > >>>> 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 > > ... > > read more » -- 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.
