Re: Re: Reworking import statements (proposal)

Here's a radically simplifying proposal: Let's only have relative
imports! Oh wait, Scala already does that ;-).

In seriousness, Scala has a very simple model of name resolution and I
intend to keep it that way. Scopes are nested, packages are scopes,
and every name resolution goes inside out. What could be simpler?

Best,

 - Martin

On Thu, Apr 14, 2016 at 6:39 PM, Piotr Tarsa <[email protected]> wrote:
>
>> 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.



-- 

Martin Odersky
EPFL and Lightbend

-- 
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.