who can tell me why

[Tom Fredriksen]

but there IS a point to using
full class names instead of ".*" in import statements: to avoid name
conflicts.

If you are thinking of the problem of two packages having the different
classes with same names, then using the complete package name in the
code statement is the only viable solution, for readability and code safety.
If you are thinking of two classes with the same name in the same
package, is that even legal?

The consultant gave a "bad reason",

The main point was that he wanted to have it his way by force if necessary.

/tom

 

[Oliver Wong]

If you are thinking of the problem of two packages having the different
classes with same names, then using the complete package name in the code
statement is the only viable solution, for readability and code safety.
If you are thinking of two classes with the same name in the same package,
is that even legal?

I was thinking of the former. Just as an example off the top of my head,
maybe you're writing a class which does SQL stuff, and puts things into
collections. If you write:

import java.sql.*;
import java.util.*;

You'll get a collision with the classname "Date", because there exists a
java.sql.Date and a java.util.Date. If you instead wrote:

import java.sql.Connection;
import java.sql.Date;
import java.sql.ResultSet;
import java.sql.Statement;
import java.util.ArrayList;
import java.util.List;

you avoid the name collision.

- Oliver

 

[Tom Fredriksen]

I was thinking of the former. Just as an example off the top of my
head, maybe you're writing a class which does SQL stuff, and puts things
into collections. If you write:

import java.sql.*;
import java.util.*;

You'll get a collision with the classname "Date", because there exists a
java.sql.Date and a java.util.Date. If you instead wrote:

import java.sql.Connection;
import java.sql.Date;
import java.sql.ResultSet;
import java.sql.Statement;
import java.util.ArrayList;
import java.util.List;

Only if you do not specify the package name in front of the class name
when declaring the variable, would there be a problem. But I see your
point though, basically there is pro and cons to the issue.

/tom

 

[Monique Y. Mudama]

Only if you do not specify the package name in front of the class name
when declaring the variable, would there be a problem. But I see your
point though, basically there is pro and cons to the issue.

Why would you routinely specify the package name in a declaration,
rather than just importing it?

The only reason I can think of for doing so is when you actually do
use both Dates (or whatever other class has a name conflict) in a
file.

 

[Roedy Green]

I have no problem with your point of view or that you express or
discussing the postives and the negatives of it, but please refrain from
trying to impress on me or others your view. Thats not really very
becoming, of anybody.

Your attitudes are typical of the young and self taught. The real
world is much bigger. You are already running into the friction here
is only a tiny foretaste of the volcanic fury you will generate if you
keep those attitudes on team project.

I am not some sort of Nazi who want's uniformity in order to control
others. I have been pushing for the SCID to allow maximum individual
flexibility without infringing on the rights of others to read the
code the way THEY like. See http://mindprod.com/jgloss/scid.html

If you want to rebel, do it with something that matters, not with a
nose ring or archaic Java syntax.

 

[Roedy Green]

Although I have worked on several teams, I have never encountered
these "EXTREMELY tight coding conventions" of which you speak, just
local recommendations that may or may not vary among code shops.

Either you ban beautifiers, which I see as like asking people to code
with one arm, or you insist than the beautifiers be synchronised with
the same rules.

I have worked in both kinds of shop.

 

[Tom Fredriksen]

Why would you routinely specify the package name in a declaration,
rather than just importing it?

Not routinely, just when its an issue. In any case, I am not saying one
way or the other, I am just making a remark.

/tom

 

[Tom Fredriksen]

Your attitudes are typical of the young and self taught. The real
world is much bigger. You are already running into the friction here
is only a tiny foretaste of the volcanic fury you will generate if you
keep those attitudes on team project.

I am not some sort of Nazi who want's uniformity in order to control
others. I have been pushing for the SCID to allow maximum individual
flexibility without infringing on the rights of others to read the
code the way THEY like. See http://mindprod.com/jgloss/scid.html

If you want to rebel, do it with something that matters, not with a
nose ring or archaic Java syntax.

You are calling me a rebel because I have a legitimate preference for
some things? Come on, you are loosing the discussion, and you dont want
to admit it.

/tom

 

[Tom Fredriksen]

Your attitudes are typical of the young and self taught. The real
world is much bigger. You are already running into the friction here
is only a tiny foretaste of the volcanic fury you will generate if you
keep those attitudes on team project.

I am not some sort of Nazi who want's uniformity in order to control
others. I have been pushing for the SCID to allow maximum individual
flexibility without infringing on the rights of others to read the
code the way THEY like. See http://mindprod.com/jgloss/scid.html

If you want to rebel, do it with something that matters, not with a
nose ring or archaic Java syntax.

I forgot to say, there is only a couple of people I have met (of about
150 programmers I have worked with over the last 12 years both at work
and while at university), that have really been annoyed with such minor
issues.
You and the consultant are the prime candidates though.

/tom

 

[Roedy Green]

You are calling me a rebel because I have a legitimate preference for
some things? Come on, you are loosing the discussion, and you dont want
to admit it.

If you insist on top posting you will drive some people in this forum
apoplectic. I would not mind in the least personally, but I would not
want you doing it, to preserve the peace.

Every group has its conventions. You are new and inexperienced. You
are stomping over established conventions, including ones you don't
even understand. It is as if you were thumbing your nose at everyone.

I am going to plonk you. I am already overstating my case. I have not
the energy to deal with you. I don't want to explode in the nasty ad
hominem that I can feel brewing.

The humour is I can see how my own behaviour, similar to yours,
especially in my early career, was so grating on others.

 

[Patricia Shanahan]

If you are thinking of the problem of two packages having the different
classes with same names, then using the complete package name in the
code statement is the only viable solution, for readability and code
safety.

The potential problem with wildcard import is the risk that the program
will stop compiling without any source code change. Addition of a class
name to a package you are importing can make an existing identifier
ambiguous.

If you use only class imports, that will never happen, because the new
identifier is not imported.

Patricia

 

[Tom Fredriksen]

Every group has its conventions. You are new and inexperienced. You
are stomping over established conventions, including ones you don't
even understand. It is as if you were thumbing your nose at everyone.

you need to explain to me what conventions I am breaking and how you
think I am inexperienced. Guide me, please.

I am going to plonk you.

For disagreeing with you? on this topic? Come on, its a discussion
group, if you don't want to discuss a particular topic with me then you
don't have to. but plonking is for when the person never contributes to
any discussions. Have been a troll all the time and not contributed even
a little bit with my postings the last couple of months? Well, its your
prerogative, you do what you feel like.

/tom

 

[Roedy Green]

The potential problem with wildcard import is the risk that the program
will stop compiling without any source code change. Addition of a class
name to a package you are importing can make an existing identifier
ambiguous.

If you use only class imports, that will never happen, because the new
identifier is not imported.

The other advantage of the explicit list is it gives you a very quick
overview of what the class is up to, and what it CAN'T be doing.

The tools in Eclipse and IntelliJ to flip back and forth between * and
explicit notation, pruning excess and also adding needed imports make
maintaining such an explicit list painless.

Without such a tool, maintaining the list is a pain.

 

[EJP]

instead of writing

if(some_var==SOME_MAGIC_NUMBER)
do something

we write

if(SOME_MAGIC_NUMBER==some_var)
do something

(with SOME_MAGIC_NUMBER being a C define), do you see why one would
write it like this?

No I don't actually. This is an obsolete practice from C whose purpose
is to avoid the subtle bug that arises if you type '=' instead of '=='.
In Java the problem cannot arise, because it is a compile error:
assignment doesn't have a boolean value in Java.

 

[Patricia Shanahan]

No I don't actually. This is an obsolete practice from C whose purpose
is to avoid the subtle bug that arises if you type '=' instead of '=='.
In Java the problem cannot arise, because it is a compile error:
assignment doesn't have a boolean value in Java.

Assignments of boolean expressions do have type boolean:

if(someBooleanVar = (x>3))

compiles and can change the value of someBooleanVar.

I am not at all sure that making assignments expressions, rather than
statements, was a good thing in Java. It was more useful in C, because
of the extensive use of macros that had to be expressions.

Patricia

 

[Gordon Beaton]

Either you ban beautifiers, which I see as like asking people to code
with one arm, or you insist than the beautifiers be synchronised with
the same rules.

I have worked in both kinds of shop.

You certainly presume to know a lot about places you *haven't* worked.

/gordon

 

[Tom Fredriksen]

No I don't actually. This is an obsolete practice from C whose purpose
is to avoid the subtle bug that arises if you type '=' instead of '=='.
In Java the problem cannot arise, because it is a compile error:
assignment doesn't have a boolean value in Java.

I was thinking about C, not java. So in C its valid way of doing it.

/tom

 

[Luc The Perverse]

I was thinking about C, not java. So in C its valid way of doing it.

Either was is valid in C

 

[Tom Fredriksen]

Either was is valid in C

Yes, that was my point.

/tom