Re: Reworking import statements (proposal)
Oliver Ruebenacker <[email protected]> Wed, 13 Apr 2016 09:59:40 -0400
| Newsgroups | gmane.comp.lang.scala |
|---|---|
| Message-ID | <CAA=X4OAYYnkNymSKA3uMjNd_6xV6vrZ22jmSWNkyKqanSuX5tQ@mail.gmail.com> |
Hello,
Example of confusing imports:
import a.b.c._
import x.y.z
It is unclear which of the following the last line actually imports:
(1) _root_.x.y.z
(2) _root_.a.b.c.x.y.z
I think this is mostly an issue when reading tutorial examples that tend
to heavily use wildcard imports.
On the other hand, multiple wildcard imports in the same scope can be
confusing even without the use of relative imports, because it is unclear
where things come from.
Maybe the solution is to discourage wildcard imports.
Best, Oliver
On Wed, Apr 13, 2016 at 8:30 AM, Simon Schäfer <[email protected]> wrote:
>
>
> On 04/13/2016 01:02 PM, Piotr Tarsa wrote:
>
> 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:
>
> 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. 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.
>
>
> 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.
>
>
> --
> 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.
>
--
Oliver Ruebenacker
Senior Software Engineer, Diabetes Portal
<http://www.type2diabetesgenetics.org/>, Broad Institute
<http://www.broadinstitute.org/>
--
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.