Feature request: aliasing classes at import

[Marek Kozieł]

Hi,

Personally, I'm strongly against aliasing in Java. This can be good
in some dead language with that people work on same project for years but
in the situation where person can be assigned 2 project for about a
month is not efficient at all. If Java is going to hide conflicts in
names, we should answer the question 'Who will pay for that'?
I actually meet situation where between two projetcs there is such a
corresponding logic
having their names partially swapped:
Project1:
  logicX = NameA
  logicY = NameB

Project2:
  logicX = NameB
  logicY = NameC
Therefore NameB brings a lot of confusion.
The same would be with aliases - they are easy to use and fast to learn -
so some people will end using aliases instead of names. But I doubt
that reading such a code would be peasant. So if someone use 20
aliases, I'll have to learn them all to analyse more complex code(?) What
will happen when we have more programmers and more aliases +even
more after adding historical ones?


> import java.util.Date : UDate;
> import java.sql.Date : SDate;

Btw.
Maybe you should consider increasing line width in editor .


> I would not limit this than just to class names but rather expand idea of selective aliasing to methods and fields.
Notice that aliases in language create many layers for translation because
they act the same as translating (en2fr).
Worst of it would be the lack of direct force to make aliases the same at
global scope and allow for only one translation to exists.


The only way I can now think about aliases to exists and not make life
harder is: limit them to partially qualified classes with some
prefix/suffix like '...':

import x.y.z.w.ClassName as ...y.ClassName;
import a.b.z.w.ClassName as ...b.ClassName;

or

import x.y.z.w.ClassName as ...x.y.ClassName;
import a.b.z.w.ClassName as ...a.b.ClassName;

or

import x.y.z.w.ClassName as ...y.ClassName; // y is characteristic
import a.b.z.w.ClassName as ...a.ClassName; // a is characteristic

When we consider that package is often quite
long:pl.com.firm.project.module.subModule..
so such approach would help in most difficult cases. As well people
would bring more consideration to class localization - which could
bring more happiness to programmer life.
Also IDE would have easier task to deal with:
- new conflict classes could be automatically suggested to be aliases
(along with suggestion for previous class with the same name).
- conflicted classes appearing as class and aliases could be reported
as warning (...with exclusion of standard classes).
- class names could be generally shorten / because programmers could
bring short name in order to make it similar to other existing class
having in thought using it with aliases(alias could be suggested in
annotation?) rather than extending class name as it is practised now
days.

Problems I see:
- refactor can become more time consuming.

Regards.
Lasu aka Marek Kozieł       http://lasu2string.blogspot.com/