Oops, forgot to copy the list for the below response:

I am not quite sure that I agree that it is a blunt solution. The reason is
that according to the specification, classes from two packages are always
available: those from the current package and from java.lang. This means
that unless you explicitly specify that another x.y.String class should be
used, the one from java.lang will be used. So in my opinion, the solution
only does what the compiler does anyway. It uses classes imported implicitly
if possible, and tries to import them explicitly otherwise. I think that
more than 99.9% (or even 99.99%) of all uses of String are java.lang.String,
so it is also better to optimise for that case than for the rare one when
another String is needed. And the same probably goes for most of the classes
in java.lang.

I think that a behaviour similar to that is more intuitive than requiring
users to configure some variables since only power-users are likely to be
aware of the existence of those variables, and if the default behaviour is
unexpected, it will be ticking people off. But although I think the
behaviour is right, I am not sure about the implementation, which most
likely could be better.

Does that make sense?

/ Petter 

> -----Ursprungligt meddelande-----
> Från: Paul Kinnucan [mailto:[EMAIL PROTECTED] 
> Skickat: den 8 juli 2004 07:00
> Till: Petter Måhlén
> Kopia: [EMAIL PROTECTED]
> Ämne: Jde-import.el
> 
> Petter Måhlén writes:
>  > Hi Paul,
>  > 
>  > The patched jde-import.el is attached. Basically, what it 
> does is to create
>  > the list of fully expanded potential classes to import for 
> each token, as
>  > before. Then, it checks if any of the classes belongs to 
> java.lang or the
>  > current package, and if so, excludes all of them. 
> 
> Hi Petter,
> 
> This seems to be a rather blunt solution to the problem of 
> synonyms for
> java.lang classes. What if I really do want xyz.String instead of 
> java.lang.String? 
> 
> May I suggest the following solution. Suppose the JDEE includes, in
> addition to jde-import-exclude-packages, jde-import-exclude-classes?
> The new variable allows you to exclude individual classes without
> excluding an entire package. In particular, you coulde exclude
> xyz.String and java.lang.String without exculding other classes
> from the xyz package.
> 
> Paul
> 
> 

Reply via email to