exports (implicit imports ?)

[Ruslan Shevchenko]

Good day, colleagues.

During writing libraries for industrial-style usage I often feel the lack of  'export' construct (which in scala, I think can be descripted as 'implicit import')

Idea is next:

Implicit import declaration look's like normal import declaration but marked as implicit

Allow implicit import decalaration be present in object. Names, imported from such declaration must be  visible in object itself

and elsewhere, where object scope if available.  I.e.  importing object we also import all names from implicit imports in one.  

Yet one sufficient issues -- multiple import of same name via implicit declaration should not lead to ambiguity during implicit resolution:

if we import some name twice, it must be the same name, not copy.

Examples:

A)

import com.mycompany

package object peristence
{
implicit import com.mycompany.persistence.dsl._
}

Export all names from com.mycompany.persistence.dsl  inot com.mycompany.persistence
i.e.  com.mycompany.persistence.dsl.Sentence,  is visible in

//  should it be visible  as com.mycompany.persistence.Sentence or as  com.mycompany.persistence.dsl.Sentence - issue to discuss.

I guest this is more consistent, but may be simplest variant more fool-proofed.

B)

object fullscala
{
implicit import language._
implicit import language.experimental._

}

import import fullscala._   enable usage of all  stable and experimental language usage.

So, questions:

 - Is exists SIP with something related ?

 - If not:  may be time to start one ?

[Paul Phillips]

On Fri, Aug 24, 2012 at 10:16 AM, Ruslan Shevchenko <ruslan.s....@gmail.com> wrote:

 - Is exists SIP with something related ?

The idea has been proposed regularly since at least 2008.  I think there might have been a SID at one point (that being one of the SIP ancestors.) There's definitely plenty of archived discussion.

[Ruslan Shevchenko]

So, here is a short summary of related links:

Original export proposal https://wiki.scala-lang.org/display/SYGN/Export  

Exprt feature request in 2008: http://scala-programming-language.1934581.n4.nabble.com/Feature-request-syntactic-sugar-for-imports-td1940637i20.html
                                                http://scala-programming-language.1934581.n4.nabble.com/Suggestion-an-export-statement-td1998225.html

'exprt is dead thread in scala-users" http://www.scala-lang.org/node/9719

About implicit import in scala SIP, but with completely other meaning: https://groups.google.com/forum/?fromgroups=#!topic/scala-sips/m1ob6s_-puU
(imho -- must be import implicit, i.e. just shortcut for import and immediate implicit redefinition)

Ok. next question -- is it make sense to formulate updated 'implicit import SIP'  (looking at Jamie Webb original proposal as on starting point)  ?

Are any interesting parties there ?

[Russ Paielli]

I don't have time to look at all those links, but I like the general
idea of "export" or whatever you want to call it. In fact, I suggested
it myself a while back. I tend to have a list of imports at the top of
my source files, and I would prefer to consolidate them for aesthetics
and convenience.

This issue first came to my attention when I wrote my Scalar package
("Efficient Scalars in Scala": http://russp.us/scalar-scala.htm). This
package allows users to define their own package of physical units (or
they can use one of the predefined packages of units). Let's say you
have a units package called "myUnits". To use it, you import the
following:

import scalar._
import myUnits._

The first import provides access to the operators and such for any
package of units, and the second provides access to the actual units
to be used. There is no significant use case where you want the second
import without the first. If export were available, the user could
omit the first import, which would be cleaner and more convenient. It
would be less to remember for using the REPL as a units-aware
calculator, for example.

--Russ P.

--
http://RussP.us

[Haoyi Li]

I'm all for this idea. It'd let you keep your imports DRY, rather than
tediously importing the same set of things many times in many files.
The loss in explicitness is mitigable with an IDE lile intellij, and
the gain in DRY would be awesome.

In theory, anyway. There are probably numerous practical/implementation
concerns i'm not aware of
From: Russ Paielli
Sent: 8/24/2012 3:14 PM
To: Ruslan Shevchenko
Cc: scala-...@googlegroups.com
Subject: Re: [scala-debate] exports (implicit imports ?)

[Russ Paielli]

I'm sorry, but what does DRY stand for?

I'm sure the whole idea is ripe for abuse, but I think it does have a
legitimate use. Whether the potential for abuse outweighs the
advantages in simplicity and convenience is an open question.

--Russ P.

--
http://RussP.us

[Naftoli Gugenheim]

Don't Repeat Yourself, i.e., the less repetition the less room for bugs.