Newbie question - Disadvantages of java

T

Thomas G. Marshall

xarax said:
"Thomas G. Marshall"


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.

That's NOT "REASONING". That's factual information.

My posts are discussing the /why/ and /what if/, not the /what is/.
 
T

Timo Kinnunen

"Thomas G. Marshall"
That's NOT "REASONING". That's factual information.

My posts are discussing the /why/ and /what if/, not the /what
is/.

Perhaps it serves as a hint to implementers to make null reference
such a special object and as a guarantee that this is legal. If null
didn't have a type, this technique would be far less obvious.
 
?

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

Timo said:
Perhaps it serves as a hint to implementers to make null reference
such a special object and as a guarantee that this is legal. If null
didn't have a type, this technique would be far less obvious.
Perhaps the hintk is to design an object oriented language where
everything is an object, without primitives, so anything can be compared
to or set to nil, which itself is a singleton instance of an undefined
object. Pretty straightforward.
 
R

Ronald Fischer

Thomas G. Marshall said:
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.

Well, the type of the *expression* 32767 is int; the implicit coercing of an int
*literal* in an assignment is a property of the assignment (or initialization)
*statement*. Kind of "syntactic sugar", which allows you to omit the cast
just for convenience.

Ronald
 
T

Thomas G. Marshall

Ronald Fischer said:
"Thomas G. Marshall"


Well, the type of the *expression* 32767 is int; the implicit
coercing of an int
*literal* in an assignment is a property of the assignment (or
initialization)
*statement*. Kind of "syntactic sugar", which allows you to omit the
cast
just for convenience.

You just repeated what I said.
 
R

Ronald Fischer

Thomas G. Marshall said:
You just repeated what I said.

Don't think so, but maybe I should clarify my point:

I wanted to stress that the ability of being able to deduce a type when seen
just an expression, is regarded A Good Thing by most programming language
designers (for those languages at least, where the compiler is intended to do
type checking). This has nothing to do with the rules of what to do with such
an expression (for instance under what condition assignment is allowed).

In this respect, *every* expression in Java has a well defined type, and if you
would make null typeless, then you would have one exception from the rule,
which means a slight loss of orthogonality.

Of course one might ask wheather having defined typing for every expression,
is A Good Thing only for the implementor of the language, or for the user
as well. But this is not really a problem: Issues such as "the type of null"
probably don't pop up in introductory texts on Java, and I guess that many
Java programmers see such questions more as having philosophical quality.
Of course they have to go to the language definition, as this is the
reference for the language implementor. When we discuss such interestic,
but somewhat esoteric topics, we are doing it with the implementor's hat
on our head.

Ronald
 
T

Thomas G. Marshall

Ronald Fischer said:
"Thomas G. Marshall"


Don't think so, but maybe I should clarify my point:

....[thwack]...

Thanks for the clarification, but that is covered precisely by my statement:

<self-quote>
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 s[h]orts without cast.
</self-quote>
 
T

Thomas G. Marshall

Ronald Fischer <[email protected]> coughed up the following:

....[rip]...

In this respect, *every* expression in Java has a well defined type,
and if you
would make null typeless, then you would have one exception from the
rule,
which means a slight loss of orthogonality.


PRECISELY. But my argument is still that there is a "loss of orthogonality"
anyway. Either way you break the orthogonality with either of the two rule
breaks:

1. (the way I propose): null is a type-less literal (as long as java
doesn't have a reference-type) assignable to any object reference
variable.

...or...

2. (the way java does it): null is a value of type null. This type
has the special property that it is assignable to any other
object type, and without cast.

Remember that #2 breaks the rule because without a inheritance/interface
relationship, you cannot do this:

Thing thing = new UnrelatedThing();
 
R

Ronald Fischer

Thomas G. Marshall said:
PRECISELY. But my argument is still that there is a "loss of orthogonality"
anyway. Either way you break the orthogonality with either of the two rule
breaks:

1. (the way I propose): null is a type-less literal (as long as java
doesn't have a reference-type) assignable to any object reference
variable.

...or...

2. (the way java does it): null is a value of type null. This type
has the special property that it is assignable to any other
object type, and without cast.

Agreed, though I believe (2) would be bad only if this "exception from the rule"
would apply *only* to null, but not to other literals too. But, as you pointed
out in your example with assigning an int literal to a short variable without a
cast, there is no hope to introduce orthogonality here anyway.

My guess is that, aside of this, the way null is defined now eases the job for
the language implementor, though I'm not proficient enough in this subject
to decide this. Unfortunately, no professional compiler writer seems to follow
this thread, otherwise I bet we would already have a comment on that matter...

Ronald
 
R

Roedy Green

From casual observation, you are just playing with words. It is a
difference that does not make a difference. If your definition were
accepted, what sorts of code would become legal and what would become
illegal?
 
T

Thomas G. Marshall

Roedy Green said:
From casual observation, you are just playing with words. It is a
difference that does not make a difference. If your definition were
accepted, what sorts of code would become legal and what would become
illegal?

Not the issue. What /is/ the issue is that the way it currently is confuses
more engineers than the way I propose. Establishing a special type to hold
a special value, both the exact same name n.u.l.l., and only that 1 value is
allowed for that special type, and furthermore to allow that type to be
coerced into any other non-inherited type, is a goofy set of explanations to
have in a language spec.

In theory, the way it reads now makes it sound like

(null instanceof null)

just might evaluate to true, depending if the compiler always looked at the
first operand as the value, and the 2nd as the type, regardless.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top