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]>
> [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]>[email protected]>
> > To: The Java Posse < <[email protected]>
> [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>
> 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]>
> [email protected].
> > To unsubscribe from this group, send email to
> > <javaposse%[email protected]>
> [email protected].
> > For more options, visit this group at
> > <http://groups.google.com/group/javaposse?hl=en>
> 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]>
> [email protected].
> > To unsubscribe from this group, send email to
> <javaposse%[email protected]>
> [email protected].
> > For more options, visit this group at
> <http://groups.google.com/group/javaposse?hl=en>
> 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]<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].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
