Why Can’t You Import Packages?

[Lawrence D'Oliveiro]

Consider a piece of code which wants to use two different classes,
com.example.android.sqlite.Useful and com.example.android.mysql.Useful. Your
only reasonable options are:

1) Choose one to specify in an import statement so you can use its name
unqualified. The other class will have to be referred to by its fully
qualified name
2) Don’t bother importing either, use the full name for both.

There is no way you can do something like

import com.example.android.sqlite;
import com.example.android.mysql;

and then be able to refer to the classes as sqlite.Useful and mysql.Useful.
Why not?

Another possibility would be the option of renaming them, Python-style, e.g.

import com.example.android.sqlite.Useful as SQLiteUseful;
import com.example.android.mysql.Useful as MySQLUseful;

This lets the client code manage its own namespace, independently of the
providers’ namespaces.

 

[Mike Schilling]

Consider a piece of code which wants to use two different classes,
com.example.android.sqlite.Useful and com.example.android.mysql.Useful.
Your
only reasonable options are:

1) Choose one to specify in an import statement so you can use its name
unqualified. The other class will have to be referred to by its fully
qualified name
2) Don’t bother importing either, use the full name for both.

There is no way you can do something like

import com.example.android.sqlite;
import com.example.android.mysql;

and then be able to refer to the classes as sqlite.Useful and
mysql.Useful.
Why not?

Another possibility would be the option of renaming them, Python-style,
e.g.

import com.example.android.sqlite.Useful as SQLiteUseful;
import com.example.android.mysql.Useful as MySQLUseful;

This lets the client code manage its own namespace, independently of the
providers’ namespaces.

I agree that it would be useful. On the other hand, C# allows something
almost exactly like your second suggestion, but it's almost never used. In
fact, when I asked about it on a C# newsgroup, most people assumed it was
something I was proposing as an extension.

 

[Knute Johnson]

Consider a piece of code which wants to use two different classes,
com.example.android.sqlite.Useful and com.example.android.mysql.Useful. Your
only reasonable options are:

1) Choose one to specify in an import statement so you can use its name
unqualified. The other class will have to be referred to by its fully
qualified name
2) Don’t bother importing either, use the full name for both.

There is no way you can do something like

import com.example.android.sqlite;
import com.example.android.mysql;

and then be able to refer to the classes as sqlite.Useful and mysql.Useful.
Why not?

Another possibility would be the option of renaming them, Python-style, e.g.

import com.example.android.sqlite.Useful as SQLiteUseful;
import com.example.android.mysql.Useful as MySQLUseful;

This lets the client code manage its own namespace, independently of the
providers’ namespaces.

You could always add two classes to your program:

class SQLiteUseful extends com.example.android.sqlite.Useful {
}

class MySQLUseful extends com.example.android.mysql.Useful {
}

 

[Andreas Leitgeb]

Consider a piece of code which wants to use two different classes,
com.example.android.sqlite.Useful and com.example.android.mysql.Useful.
[suggested way to enhance syntax of "import"]

I agree that it would be useful.

So do I.
I once proposed something along "import ... as ...;" also as a
means to create local shortcuts for parameterized generic types.
Such as: import HashMap<String,MyFoo<This,That>> as MyFooMap;
(here assuming HashMap was already imported earlier.)

Of, course, proposing something *here* has, at most, the psychological
effect of getting it off one's chest, and maybe read one or two agrees
or "noone-needs-it"s. The likeliness of getting anything rolling, here,
even if it is a sound proposal, is roughly 0.000%.
To be fair, sometimes one also gets enlightened about flaws in one's
proposal.

 

[Andreas Leitgeb]

You could always add two classes to your program:

class SQLiteUseful extends com.example.android.sqlite.Useful {
}

And how, exactly, would you cast an instance of
com.example.android.sqlite.Useful (returned by
some library fuction) to SQLiteUseful?

 

[Knute Johnson]

And how, exactly, would you cast an instance of
com.example.android.sqlite.Useful (returned by
some library fuction) to SQLiteUseful?

I'm sure there are plenty of cases where it wouldn't work.

 

[Andreas Leitgeb]

I'm sure there are plenty of cases where it wouldn't work.

So, he could always add those classes, but there are plenty of
cases where they wouldn't help. Back to the proposal?

 

[Daniele Futtorovic]

Consider a piece of code which wants to use two different classes,
com.example.android.sqlite.Useful and
com.example.android.mysql.Useful. Your only reasonable options are:

1) Choose one to specify in an import statement so you can use its
name unqualified. The other class will have to be referred to by its
fully qualified name 2) Don’t bother importing either, use the full
name for both.

There is no way you can do something like

import com.example.android.sqlite; import com.example.android.mysql;

and then be able to refer to the classes as sqlite.Useful and
mysql.Useful. Why not?

Another possibility would be the option of renaming them,
Python-style, e.g.

import com.example.android.sqlite.Useful as SQLiteUseful; import
com.example.android.mysql.Useful as MySQLUseful;

This lets the client code manage its own namespace, independently of
the providers’ namespaces.

Out of curiosity: have you spent months compiling your "questions" and
are posting them in a batch, or do you just have too much time on your
hands and make them up on the fly?

 

[Knute Johnson]

So, he could always add those classes, but there are plenty of
cases where they wouldn't help. Back to the proposal?

It's been a long time but didn't we have macros in C that would do
similar things? Maybe we need macros.

 

[Lew]

It's been a long time but didn't we have macros in C that would do
similar things?  Maybe we need macros.

Maybe we just need to write out the FQN when there are more than one
class with the same simple name in scope.

The situation is rare enough that sprained typing fingers should not
be grave risk, whiners.

 

[Knute Johnson]

Maybe we just need to write out the FQN when there are more than one
class with the same simple name in scope.

The situation is rare enough that sprained typing fingers should not
be grave risk, whiners.

I wondered where you were Lew .

 

[Arne Vajhøj]

Of, course, proposing something *here* has, at most, the psychological
effect of getting it off one's chest, and maybe read one or two agrees
or "noone-needs-it"s. The likeliness of getting anything rolling, here,
even if it is a sound proposal, is roughly 0.000%.
To be fair, sometimes one also gets enlightened about flaws in one's
proposal.

If you want things changed in Java then join the JCP.

Feedback on ideas are usually pretty negative. But that is
to be expected. Java is more than 15 years old. Any ideas
that are really good for many without any compatibility problems
are most likely already implemented. The easy problems
get fixed first - what is left us all the hard problems.

Arne

 

[Arne Vajhøj]

Maybe we just need to write out the FQN when there are more than one
class with the same simple name in scope.

The situation is rare enough that sprained typing fingers should not
be grave risk, whiners.

With a decent package and class structure and naming, then it
should happen so rare that it a complete no problem.

Arne

 

[Arne Vajhøj]

Consider a piece of code which wants to use two different classes,
com.example.android.sqlite.Useful and com.example.android.mysql.Useful. Your
only reasonable options are:

1) Choose one to specify in an import statement so you can use its name
unqualified. The other class will have to be referred to by its fully
qualified name
2) Don’t bother importing either, use the full name for both.

There is no way you can do something like

import com.example.android.sqlite;
import com.example.android.mysql;

and then be able to refer to the classes as sqlite.Useful and mysql.Useful.
Why not?

Another possibility would be the option of renaming them, Python-style, e.g.

import com.example.android.sqlite.Useful as SQLiteUseful;
import com.example.android.mysql.Useful as MySQLUseful;

This lets the client code manage its own namespace, independently of the
providers’ namespaces.

I agree completely with Mike.

C# got the last feature.

Practically none is using it.

That seems a pretty good indication that it is not necessary.

Arne

 

[Lawrence D'Oliveiro]

... C# allows something almost exactly like your second suggestion, but
it's almost never used.

Maybe certain languages attract certain kinds of programmer. I have used
such renaming in Python several times. Of course, it also helps that, in
Python, everything is a value accessible at run-time, so you can rename
anything just by assigning it to a name of your choice.

 

[Lawrence D'Oliveiro]

With a decent package and class structure and naming, then it
should happen so rare that it a complete no problem.

Going back to my example, with com.example.android.sqlite.Useful and
com.example.android.mysql.Useful, would you class that as “a decent package
and class structure and naming� If not, why not?

 

[Lawrence D'Oliveiro]

If you want things changed in Java then join the JCP.

You mean, the one that Oracle ignores?

 

[Lew]

With a decent package and class structure and naming, then it
should happen so rare that it a complete no problem.

Unfortunately there is a somewhat significant conflict between java.util.Date
and java.sql.Date and a few other types that too often appear near each other.
Thus the question of how to handle conflicts in simple names is worth
consideration.

I just don't see the harm in typing FQNs for those cases to where we must
change the language. It's a little extra typing, handled largely by our
favorite IDEs anyway. BFD.

 

[Arne Vajhøj]

You mean, the one that Oracle ignores?

The one that all changes to Java goes through.

Arne

 

[Arne Vajhøj]

Going back to my example, with com.example.android.sqlite.Useful and
com.example.android.mysql.Useful, would you class that as “a decent package
and class structure and naming� If not, why not?

No I would not.

Database specific code is not good in general.

And having a single class dealing with both SQLite and MySQL
is not good either.

Arne