Re: Reworking import statements (proposal)

> I don't see where relative imports are confusing. Can you give an example? 
> Most people nowadays let package level imports manage by the IDE.
>

Yes, IDE can be pretty good at organizing imports and convert all imports 
to use the longest sensible path possible (ie not overusing _root_ prefix). 
However, this is limited to code we're editing, not the read-only (ie not 
editable at the time of reading) code we're reading somewhere.

Imports in a smaller scope are mostly used as relative imports and they are 
> written manually. Prefixing them with something results in more typing - 
> therefore hardly an improvement.
>

A little more typing :) I'm more concerned about readability. Prefixing 
with '_.' or just '.' doesn't add serious amount of noise, but makes some 
things clearer.

Another thing is that with my proposal using relative imports would be 
somewhat discouraged and at the same time usual reformatting rules (in 
IntelliJ at least) replace relative imports with absolute ones. So no big 
negative change for people not using relative imports (ie the vast 
majority).

Can you define "absolute" and "relative"? In both cases, the first word 
> after `import ` is simply an identifier that's in scope.
>

Those definitions were invented ad-hoc, but the ad-hoc description could 
be: absolute import works without any other imports while relative import 
requires some other import. That should be perfectly unambiguous for 
top-level imports (ie outside any {} parentheses), but I haven't thought 
much about lower level scopes.

With my proposal there could be a rare case where some root package name 
clashes with some parameter/ field name in scope, thus making it impossible 
to import directly from that root package without some renaming in higher 
scope imports. Eg:

import com.{sun => com_sun} // I can't do "import {com => comP}" as it 
doesn't compile
def fun(com: Type) {
  import _.com_sun.whatever.i.need.Something
  import com._ // import from parameter
  // code here
}

Alternatively:

import com._
def fun(com: Type) {
  import _.sun.whatever.i.need.Something
  import com._
  // code here
}

Easiest way would be to just rename the parameter, but we could import from 
some eg inherited field which could make renaming more laborious. However, 
it's still manageable. In current situation we would need to use _root_ 
prefix anyway, which also isn't super nice.

I'm not aware right now of any blocking problems with my proposal.


Regards

W dniu środa, 13 kwietnia 2016 13:02:21 UTC+2 użytkownik Piotr Tarsa 
napisał:
>
> Hi,
>
> As of now relative imports (ie importing from something already imported) 
> look exactly the same as absolute ones (ie where we're importing using full 
> paths), except when explicitly starting from _root_. That is both confusing 
> (where I have relative or absolute import? it's not immediately obvious) 
> and ugly (the _root_ prefix is ugly).
>
> My proposal is to change import statements semantics to make things 
> obvious:
>
> Current state:
> import _root_.outer.inner.Member - for absolute imports (usually used when 
> there are name clashes)
> import outer.inner.Member - for absolute imports (usually used when there 
> are no name clashes)
> import inner.Member - for relative imports
> import parameter.member - for importing from parameters
>
> Proposal for next Scala version:
> import _root_.outer.inner.Member - deprecate _root_ prefix
> import outer.inner.Member - leave as it is
> import inner.Member - deprecate this form of relative imports
> import _.inner.Member - introduce this syntax for relative imports
> import parameter.member - leave as it is
>
> And a version after that:
> import _root_.outer.inner.Member - drop support for _root_prefix
> import outer.inner.Member - keep it
> import inner.Member - drop support for this form of relative imports
> import _.inner.Member - keep it
> import parameter.member - keep it
>
> What do you think about it?
>
> Regards,
> Piotr Tarsa
>

-- 
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.