Re: Re: Reworking import statements (proposal)

I would like to see syntax which helps me understand what a relative import 
is relative to. I think the underscore syntax could help.

import com.acme, _.util.Stuff

If the underscore means, this import is relative to a name introduced 
previously in this import statement, then I've learned something.

In particular, util cannot accidentally refer to some earlier imported 
identifier.

Currently, we would write

import com.acme._, util.Stuff  // on one or two lines, but which package 
has a util subpackage?

I don't think `import _.util.Stuff` by itself tells me anything I didn't 
already know.

It would be totally great if 2016 introduced another use for underscore. 
Because it makes you realize the possibilities are endless.

On Thursday, April 14, 2016 at 2:05:39 PM UTC-7, martin wrote:
>
> 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] 
> <javascript:>> 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] <javascript:>. 
> > 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.