Newbie question - Disadvantages of java

[Thomas G. Marshall]

byte, short, int, long, float, double, char, boolean, reference
variable.

Is there another?

null

3.10.7 The Null Literal
The null type has one value, the null reference,
represented by the literal null, which is formed
from ASCII characters. A null literal is always of
the null type.

http://java.sun.com/docs/books/jls/second_edition/html/lexical.doc.html#229317

 

[Gary Labowitz]

null

3.10.7 The Null Literal
The null type has one value, the null reference,
represented by the literal null, which is formed
from ASCII characters. A null literal is always of
the null type.

Hmm... interesting. But null, true, and false are all literals; that is,
they are values. I'm a little hesitant to call them "types," aren't you? And
the reference you gave seems to say there is a null type. This is a
difficult one to get my mind around since I have always held a type is the
concept of a range of values (size and encoding) a variable can contain.
I'll cogitate.

 

[Gary Labowitz]

"Thomas G. Marshall"

wrote in message news:[email protected]...

Hmm... interesting. But null, true, and false are all literals; that is,
they are values. I'm a little hesitant to call them "types," aren't you? And
the reference you gave seems to say there is a null type. This is a
difficult one to get my mind around since I have always held a type is the
concept of a range of values (size and encoding) a variable can contain.
I'll cogitate.

And it leads me ask the question: If there is a type for which you cannot
declare a variable, is there a kind of variable for it? It seems to hinge on
the fact that reference variables keep the type of the object to which they
refer. A reference which is null (refers to no object) has as its value a
null type, i.e. the type of the object to which it refers is null since
there is no object. It sort of like the void that returns from a method,
meaning of course that no value is returned. It would appear to be a
syntactic trick so that the coding has parallel coding to set a reference
variable to an object or to "no object" in the same way, e.g.
Object refer;
refer = &SomeObject;
refer = null; //refer to no object

 

[Thomas G. Marshall]

And it leads me ask the question: If there is a type for which you
cannot declare a variable, is there a kind of variable for it? It
seems to hinge on the fact that reference variables keep the type of
the object to which they refer. A reference which is null (refers to
no object) has as its value a null type, i.e. the type of the object
to which it refers is null since there is no object. It sort of like
the void that returns from a method, meaning of course that no value
is returned. It would appear to be a syntactic trick so that the
coding has parallel coding to set a reference variable to an object
or to "no object" in the same way, e.g. Object refer;
refer = &SomeObject;
refer = null; //refer to no object

I feel your pain in this regard, and you are conducting nearly exactly the
same argument I've made about this to others in the past.

null, should have been called the "null value" or the "null literal" which
is assignable to any reference type and is without type of its own.

The problem they faced, however, is this, I think: For all literals, there
needs to be a type that they belong to even BEFORE they are assigned. That
is, there are no literals per se, there are only /literals of a certain
type/.

Thus declaration assignments of

<type T> <var name> = <literal>;

are really...

<var name> of <type t> = <literal> of <type t2>;

.....and there needs to be conversion rules for t2 to t1.

That is:

float f_num = 1.0; // error. requires explicit downcast.

f_num of type float = 1.0 of type double; // error.

The 1.0 literal is of type double regardless of what you assign to it.

And thus...

Component thing = null;

thing of type Component reference = null of type null;

The null literal is of type null regardless of what you assign it it. Why
not simply be this:

thing of type Component reference = null of type Component
reference.

I think it's because they want the RHS of the equation to establish it's
type devoid of the LHS. But that doesn't make any sense, since they
/already/ play games to that extent:

short s_num = 32767;

Was 32767 a short or int literal? And in this error case:

short s_num = 32768; // error. Can't fit in signed 16 bits

is the 32767 an int literal simply because it cannot fit in the short?

Or are both numbers in these last two examples of type int with "special"
conversion rules?

In any case, it seems like there is precedent for having the RHS mutate to
the needs of the LHS.

 

[Jon Skeet]

Hmm... interesting. But null, true, and false are all literals; that is,
they are values. I'm a little hesitant to call them "types," aren't you? And
the reference you gave seems to say there is a null type. This is a
difficult one to get my mind around since I have always held a type is the
concept of a range of values (size and encoding) a variable can contain.
I'll cogitate.

Not necessarily - you can only declare a variable if the type has a
name. From the JLS section 4.1:

<quote>
There is also a special null type, the type of the expression null,
which has no name. Because the null type has no name, it is impossible
to declare a variable of the null type or to cast to the null type.
</quote>

Other than that, null is an ordinary type, I believe. There is an
implicit conversion from a value of the null type (i.e. the null
literal) to any reference type, but no reverse conversion.

This is different from true and false, because those are literals of
the boolean type.

From a brief look at the C# spec, I think it handles null in the same
way.

 

[Gary Labowitz]

Not necessarily - you can only declare a variable if the type has a
name. From the JLS section 4.1:

<quote>
There is also a special null type, the type of the expression null,
which has no name. Because the null type has no name, it is impossible
to declare a variable of the null type or to cast to the null type.
</quote>

Other than that, null is an ordinary type, I believe. There is an
implicit conversion from a value of the null type (i.e. the null
literal) to any reference type, but no reverse conversion.

This is different from true and false, because those are literals of
the boolean type.

From a brief look at the C# spec, I think it handles null in the same
way.

All this falls into the "fun and games" category, but it does force me to
change all my materials to say: "There are ten types defined in Java, nine
of which you can use to declare variables, and one of which you can use to
.... ummm ... what?"

I have always taught that null, true, and false are literals, but never gave
a thought to what TYPE they each are.
With regard to the byte x = 127; quandary I have taught that though 127 is a
literal int, since it can fit into a byte the compiler truncates it, etc.
for other LHS types.

 

[Jon Skeet]

With regard to the byte x = 127; quandary I have taught that though 127 is a
literal int, since it can fit into a byte the compiler truncates it, etc.
for other LHS types.

Yes - and after a little while of trawling through the JLS, that's
explained in section 5.2:

<quote>
In addition, a narrowing primitive conversion may be used if all of the
following conditions are satisfied:

The expression is a constant expression of type byte, short, char or
int.

The type of the variable is byte, short, or char.

The value of the expression (which is known at compile time, because it
is a constant expression) is representable in the type of the variable.
</quote>

It must be annoying for language specification authors to have to jump
through hoops like this in order to get a usable language!

 

[Thomas G. Marshall]

Yes - and after a little while of trawling through the JLS, that's
explained in section 5.2:

<quote>
In addition, a narrowing primitive conversion may be used if all of
the following conditions are satisfied:

The expression is a constant expression of type byte, short, char or
int.

The type of the variable is byte, short, or char.

The value of the expression (which is known at compile time, because
it
is a constant expression) is representable in the type of the
variable. </quote>

It must be annoying for language specification authors to have to jump
through hoops like this in order to get a usable language!

Well, I hate the hoops we all have to jump through just to understand it.

Being the person that opened up this pandora's null box, I'd still like to
know precisely /why/ null need be of type null.

My long winded musings in a prior post aside, just what would have been so
bad about having null as a literal of object (reference) type, the way true
and false are of boolean?

 

[Jon Skeet]

Thomas G. Marshall

Well, I hate the hoops we all have to jump through just to understand it.

Being the person that opened up this pandora's null box, I'd still like to
know precisely /why/ null need be of type null.

My long winded musings in a prior post aside, just what would have been so
bad about having null as a literal of object (reference) type, the way true
and false are of boolean?

When you say "object (reference) type" do you mean as in
java.lang.Object? If so,

String x = null;

wouldn't work.

It has to be of *some* special type so that the above (and everything
like it, including Foo(null)) can work.

 

[Thomas G. Marshall]

Thomas G. Marshall


When you say "object (reference) type" do you mean as in
java.lang.Object? If so,

I see your point, and I was kind of hopping around it two posts ago, but
there /really/ is no reason that I can see that null isn't a typeless
special literal value.

String x = null;

wouldn't work.

Best explanation so far.

It has to be of *some* special type so that the above (and everything
like it, including Foo(null)) can work.

Again, since this is the part of the spec that says words to the effect of
"this is an exception to the rule", it seems that it would simply be easier
to make null a special literal assignable to any object variable, rather
than a special value of a special type which is assignable to any object
variable.

 

[Michael Besosa]

But that's exactly what the special null type accomplishes, while
avoiding the irregularity of having a singular value with no type.

 

[VisionSet]

But that's exactly what the special null type accomplishes, while
avoiding the irregularity of having a singular value with no type.

Warning from someone who has followed all the posts in the thread.

You are about to go round in circles!

Everyone actually seems to agree on the basic issues.

 

[=?ISO-8859-1?Q?Thomas_Gagn=E9?=]

The disadvantages of Java have a lot to do with the (existence)
treatment of primitive types. Null couldn't be an object because
primitives exist, as well as special types, and as was pointed out
earlier, they couldn't be assigned back and forth. Even if Null were a
reference type you wouldn't be allowed to subclass it because TPTB would
have forseen no reason to, and would have declared it final. Or perhaps
for optimization reasons they would have made it final the same way as
String.

Learning Java I think may be especially difficult for COBOL programmers.
My first class of COBOL programmers wondered why anyone was interested
in bytes, shorts, longs, floats, doubles, etc. What possible business
reason was there to know how many bits were used?

That some variables were treated differently than other variables
(primitives v. reference types) was similarly confusing.

Oddly (or not) they took quite naturally to Java's use of static method
classes to operate on objects rather than imparting functionality to the
objects themselves through instance methods.

 

[Sudsy]

Thomas Gagné wrote:

Learning Java I think may be especially difficult for COBOL programmers.
My first class of COBOL programmers wondered why anyone was interested
in bytes, shorts, longs, floats, doubles, etc. What possible business
reason was there to know how many bits were used?

<snip>

That's hilarious! Wasn't the primary reason for the Y2K fiasco the
desire to not waste "bits" by including the century in the date?!
What a comedian...

 

[Ronald Fischer]

Being the person that opened up this pandora's null box, I'd still like to
know precisely /why/ null need be of type null.

My personal guess: This is because perhaps the following underlying
principle was
implicitly assumed when designing the language:

"Every expression shall of a certain type (irrespective of the context
in which it is
used)".

If one accepts this, then the you have no other chance than to invent
a 'null' type
for the expression (null), since none of the other existing types
would fulfil the
principle.

Of course one might ask wheather or not it is a good thing to
determine the type of an
expression without looking at the context. I am aware of at least one
language - Ada
- where the context is used in determining the type of an expression
in order to have
proper overload resolution (For language purists: I know, this is not
exactly the
same, because in order to find out the proper *candidates* for
overload resolution,
you still have first to analyze the sub-expressions without looking at
the
context, but at least it is similar in spirit). But you don't find
this principle
in many languages, because expressions are easier to understand if you
don't have
to look at the context to grasp their meaning.

Of course, in practice, a programmer does not have to *think* of the
null value
as a special null-type, because the context where null can be used is
always so
simple that it is immediately obvious to which type null is coerced.
Nevertheless
the null-type rule is a good thing for sake of orthogonality in the
language
definition.

Ronald

 

[Thomas G. Marshall]

The disadvantages of Java have a lot to do with the (existence)
treatment of primitive types. Null couldn't be an object because
primitives exist, as well as special types, and as was pointed out
earlier, they couldn't be assigned back and forth. Even if Null were
a reference type you wouldn't be allowed to subclass...

But these are only self imposed limitations.

We're talking about language design: given a clean slate (not the way it
currently is), there is *no reason* that null couldn't have been a type-less
literal assignable only to objects.

Remember, they make such ad-hock rules already. The 32768 below is
assignable to a short without cast:

short s = 32768;

....while if they were truly worried about types of literals, then they would
follow the same rule that they do for doubles:

float f = 5.5; // error: must cast double /down/ to float.

 

[Thomas G. Marshall]

But these are only self imposed limitations.

We're talking about language design: given a clean slate (not the way
it currently is), there is *no reason* that null couldn't have been a
type-less literal assignable only to objects.

Remember, they make such ad-hock rules already. The 32768 below is
assignable to a short without cast:

short s = 32768;

WHOA: sorry: I meant----32767.

 

[Thomas G. Marshall]

"Thomas G. Marshall"


My personal guess: This is because perhaps the following underlying
principle was
implicitly assumed when designing the language:

"Every expression shall of a certain type (irrespective of the context
in which it is
used)".

Then what is the type of the expression "32767" ?

short s = 32767;

It seems according to the specification that it is indeed an int, but there
is a "special rule" for assignments that allow it to be downwardly
assignable to sorts without cast.

Special rules abound. Making "null" a typeless literal seems really far
more benign a rule-break than making it a value of a special type that is
always assignable without cast:

Thang thang = null;

What's worse:

Having a type value that is assignable to all object types without cast?
or
Having a litteral that is assignable to all object types? (remember, no
cast, because it has no type).

 

[Thomas G. Marshall]

But that's exactly what the special null type accomplishes, while
avoiding the irregularity of having a singular value with no type.

A /literal/ with no type. A value would technically always be /of/ a type.

 

[xarax]

Then what is the type of the expression "32767" ?

short s = 32767;

It seems according to the specification that it is indeed an int, but there
is a "special rule" for assignments that allow it to be downwardly
assignable to sorts without cast.

Special rules abound. Making "null" a typeless literal seems really far
more benign a rule-break than making it a value of a special type that is
always assignable without cast:

Thang thang = null;

What's worse:

Having a type value that is assignable to all object types without cast?
or
Having a litteral that is assignable to all object types? (remember, no
cast, because it has no type).

The reasoning is that "null" has a built-in type that implicitly
inherits from all reference types (the only case of multiple
inheritance), and is thus assignable to any reference type
and castable to any reference type.