import question

On Feb 1, 2009, at 4:26 PM, Russ Paielli wrote:

> Suppose a module A imports package B, and package B imports package
> C. Shouldn't that be equivalent to module A importing package C
> also? That's what happens in Python, but apparently not in Scala. Am
> I missing something?

Imports in Scala (and Java) aren't like C "#include"s. They affect
only the source file they're in, and have no effect on other files
that in turn import it. Imports are really just a form of shorthand
that let you write "Actor" instead of "scala.actor.Actor"; you're
always free to reference any class you want without having to import
it, as long as you don't mind writing out the full name.

Opinions may vary, but this makes a lot more sense to me than the
behavior in Python. For one thing, you don't get into weird problems
trying to get two files to import each other; and for another,
changing the import statements in one source file can't have
unexpected side effects on other files that in turn import it.

—Jens

Hi Jens, Russ,

Jens Alfke wrote:
> Opinions may vary, but this makes a lot more sense to me than the
> behavior in Python. For one thing, you don't get into weird problems
> trying to get two files to import each other; and for another, changing
> the import statements in one source file can't have unexpected side
> effects on other files that in turn import it.

You're unquestionably right. There's no way that importing High-level
API X which imports Low-level API Y should implicitly import Y.

Though there is a case for providing that functionality explicitly.
Jamie Webb wrote a reasonably detailed proposal for this, though it
needs a bit more thought before it becomes a reality:

http://scala.sygneca.com/future/export

Cheers,
Jon

On Sun, Feb 1, 2009 at 5:26 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

Suppose a module A imports package B, and package B imports package C. Shouldn't that be equivalent to module A importing package C also? That's what happens in Python, but apparently not in Scala. Am I missing something? Is there a way to make it work that way? That would simplify things for the client by reducing the number of packages that need to be explicitly imported. Thanks.

I'd like to return to this post of mine from a few weeks ago and throw out an idea. I don't know if it's a good idea or not, but I think it might have some potential. Why not allow two forms of import, the usual "import," and another version called "Import". The capitalized "Import" would automatically transfer or carry over to any module that imports the package or class it appears in.

I don't know if I am typical, but I sometimes want such automatic imports to simplify matters for the client by reducing the number of imports needed. "Import" could be a way to achieve that.

Russ P.

How is this question not adequately answered by both Jens Alfke and Jon Pretty in their replies to your previous post?

As Jens pointed out, implicit importing as you suggest is dangerous/ambigous and Jon pointed to a viable (possibly viable? I'm no language expert) proposal that would somewhat enable the behaviour you want with the caveat that client classes need to invoke it explicitly, it does not come implicitly.

Ishaaq

2009/3/13 Russ Paielli <russ.paielli@gmail.com>

On Sun, Feb 1, 2009 at 5:26 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

Suppose a module A imports package B, and package B imports package C. Shouldn't that be equivalent to module A importing package C also? That's what happens in Python, but apparently not in Scala. Am I missing something? Is there a way to make it work that way? That would simplify things for the client by reducing the number of packages that need to be explicitly imported. Thanks.

I'd like to return to this post of mine from a few weeks ago and throw out an idea. I don't know if it's a good idea or not, but I think it might have some potential. Why not allow two forms of import, the usual "import," and another version called "Import". The capitalized "Import" would automatically transfer or carry over to any module that imports the package or class it appears in.

I don't know if I am typical, but I sometimes want such automatic imports to simplify matters for the client by reducing the number of imports needed. "Import" could be a way to achieve that.

Russ P.

On Thu, Mar 12, 2009 at 8:03 PM, Ishaaq Chandy <ishaaq@gmail.com> wrote:

How is this question not adequately answered by both Jens Alfke and Jon Pretty in their replies to your previous post?

I am suggesting a distinction between "import" and "Import." The capitalized version would transfer the import over to any module that imports the module it appears in.

The earlier replies said that making the current "import" do that would be a bad idea. I agree. I am not suggesting that. I am suggesting that both alternatives be available.

I am still new to Scala, so I may be naive about this, but I have already encountered cases with my own code in which I could have used this alternative form of importing. It would simplify my instructions for the users of my code because they would only need to import one thing rather than two. It's not a critical issue, but I like to make my code as simple as possible to use.

The "export" idea is fine, but it is not directly comparable with my suggestion. It is more general than what I am suggesting, but it also requires another file. It would not make sense to write another file, however small, just to eliminate an import line in a file.

Russ P.

As Jens pointed out, implicit importing as you suggest is dangerous/ambigous and Jon pointed to a viable (possibly viable? I'm no language expert) proposal that would somewhat enable the behaviour you want with the caveat that client classes need to invoke it explicitly, it does not come implicitly.

Ishaaq

2009/3/13 Russ Paielli <russ.paielli@gmail.com>

On Sun, Feb 1, 2009 at 5:26 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

Suppose a module A imports package B, and package B imports package C. Shouldn't that be equivalent to module A importing package C also? That's what happens in Python, but apparently not in Scala. Am I missing something? Is there a way to make it work that way? That would simplify things for the client by reducing the number of packages that need to be explicitly imported. Thanks.

I'd like to return to this post of mine from a few weeks ago and throw out an idea. I don't know if it's a good idea or not, but I think it might have some potential. Why not allow two forms of import, the usual "import," and another version called "Import". The capitalized "Import" would automatically transfer or carry over to any module that imports the package or class it appears in.

I don't know if I am typical, but I sometimes want such automatic imports to simplify matters for the client by reducing the number of imports needed. "Import" could be a way to achieve that.

Russ P.

--
http://RussP.us

On Fri, Mar 13, 2009 at 7:40 PM, Russ Paielli wrote:
> On Thu, Mar 12, 2009 at 8:03 PM, Ishaaq Chandy wrote:
>>
>> How is this question not adequately answered by both Jens Alfke and Jon
>> Pretty in their replies to your previous post?
>
>
> The "export" idea is fine, but it is not directly comparable with my
> suggestion. It is more general than what I am suggesting, but it also
> requires another file. It would not make sense to write another file,
> however small, just to eliminate an import line in a file.
>

I think if another file is truly required the the proposal is too
awkward. I assumed as per discussions on the lists around my export
suggestion it would be a simple top level statement such as:

package org.import.structures

class Class1
class Class2
class Class3

object Object

export {
Classes 1, 2, 3
Object._ // including all implicits
} as org.import.theLot

i.e. all in one file should be doable, but not always useful of course.

off to read the doc....

This suggestion brought to mind a different problem that we have
discussed previously and, in my opinion, not come to a satisfactory
solution for: the issues of _root_ and how relative imports can cause
unintended package collisions.

Would it be a reasonable solution to add a keyword to scala that
serves to indicate that an import is from an absolute root-relative
path? I know that adding a keyword is something of a drastic solution,
but
it might be the cleanest one. Perhaps we could appropriate ruby's "require"?

Kris

On Fri, Mar 13, 2009 at 12:40 PM, Russ Paielli wrote:
> On Thu, Mar 12, 2009 at 8:03 PM, Ishaaq Chandy wrote:
>>
>> How is this question not adequately answered by both Jens Alfke and Jon
>> Pretty in their replies to your previous post?
>
>
> I am suggesting a distinction between "import" and "Import." The capitalized
> version would transfer the import over to any module that imports the module
> it appears in.
>
> The earlier replies said that making the current "import" do that would be a
> bad idea. I agree. I am not suggesting that. I am suggesting that both
> alternatives be available.
>
> I am still new to Scala, so I may be naive about this, but I have already
> encountered cases with my own code in which I could have used this
> alternative form of importing. It would simplify my instructions for the
> users of my code because they would only need to import one thing rather
> than two. It's not a critical issue, but I like to make my code as simple as
> possible to use.
>
> The "export" idea is fine, but it is not directly comparable with my
> suggestion. It is more general than what I am suggesting, but it also
> requires another file. It would not make sense to write another file,
> however small, just to eliminate an import line in a file.
>
> Russ P.
>
>>
>> As Jens pointed out, implicit importing as you suggest is
>> dangerous/ambigous and Jon pointed to a viable (possibly viable? I'm no
>> language expert) proposal that would somewhat enable the behaviour you want
>> with the caveat that client classes need to invoke it explicitly, it does
>> not come implicitly.
>>
>> Ishaaq
>>
>> 2009/3/13 Russ Paielli
>>>
>>> On Sun, Feb 1, 2009 at 5:26 PM, Russ Paielli
>>> wrote:
>>>>
>>>> Suppose a module A imports package B, and package B imports package C.
>>>> Shouldn't that be equivalent to module A importing package C also? That's
>>>> what happens in Python, but apparently not in Scala. Am I missing something?
>>>> Is there a way to make it work that way? That would simplify things for the
>>>> client by reducing the number of packages that need to be explicitly
>>>> imported. Thanks.
>>>>
>>>
>>> I'd like to return to this post of mine from a few weeks ago and throw
>>> out an idea. I don't know if it's a good idea or not, but I think it might
>>> have some potential. Why not allow two forms of import, the usual "import,"
>>> and another version called "Import". The capitalized "Import" would
>>> automatically transfer or carry over to any module that imports the package
>>> or class it appears in.
>>>
>>> I don't know if I am typical, but I sometimes want such automatic imports
>>> to simplify matters for the client by reducing the number of imports needed.
>>> "Import" could be a way to achieve that.
>>>
>>> Russ P.
>>
>
>
>
> --
> http://RussP.us
>

just to clarify for anyone reading this, the proposal doesn't suggest
separate files (CompilationUnit).

On Fri, Mar 13, 2009 at 8:30 PM, Chris Twiner wrote:
> On Fri, Mar 13, 2009 at 7:40 PM, Russ Paielli wrote:
>> On Thu, Mar 12, 2009 at 8:03 PM, Ishaaq Chandy wrote:
>>>
>>> How is this question not adequately answered by both Jens Alfke and Jon
>>> Pretty in their replies to your previous post?
>>
>>
>> The "export" idea is fine, but it is not directly comparable with my
>> suggestion. It is more general than what I am suggesting, but it also
>> requires another file. It would not make sense to write another file,
>> however small, just to eliminate an import line in a file.
>>
>
> I think if another file is truly required the the proposal is too
> awkward. I assumed as per discussions on the lists around my export
> suggestion it would be a simple top level statement such as:
>
> package org.import.structures
>
> class Class1
> class Class2
> class Class3
>
> object Object
>
> export {
>  Classes 1, 2, 3
>  Object._ // including all implicits
> } as org.import.theLot
>
> i.e. all in one file should be doable, but not always useful of course.
>
> off to read the doc....
>

On Fri, Mar 13, 2009 at 12:39 PM, Chris Twiner <chris.twiner@gmail.com> wrote:

just to clarify for anyone reading this, the proposal doesn't suggest
separate files (CompilationUnit).

Sorry, my mistake. The "export" proposal does not require a separate file, but (if I am not mistaken again) it requires another named object that includes the items to be exported. My "Import" suggestion would not not require that. It would be more or less equivalent to making the "Imported" stuff inline. Maybe it's a trivial distinction, but I think it would be a bit cleaner in some cases.

Russ P.

On Fri, Mar 13, 2009 at 1:26 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

On Fri, Mar 13, 2009 at 12:39 PM, Chris Twiner <chris.twiner@gmail.com> wrote:

just to clarify for anyone reading this, the proposal doesn't suggest
separate files (CompilationUnit).

Sorry, my mistake. The "export" proposal does not require a separate file, but (if I am not mistaken again) it requires another named object that includes the items to be exported. My "Import" suggestion would not not require that. It would be more or less equivalent to making the "Imported" stuff inline. Maybe it's a trivial distinction, but I think it would be a bit cleaner in some cases.

 After thinking about it, I realized that I was probably mistaken again.

Say I have an object called Mathx, which imports the Math object and adds a few simple utility functions (e.g., nearest multiple and stuff like that). When I import Mathx, I don't want to have to import Math also. I want that done automatically. If I understand the "export" proposal correctly, I can achieve that in the Mathx object by using

import Math._
export Math._

My "Import" suggestion would replace those two lines with a single line:

Import Math._

This does not do everything that "export" could do, but it would simplify a significant use case.

Russ P.

On Fri, Mar 13, 2009 at 4:56 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

If I understand the "export" proposal correctly, I can achieve that in the Mathx object by using

import Math._
export Math._

My "Import" suggestion would replace those two lines with a single line:

Import Math._

This does not do everything that "export" could do, but it would simplify a significant use case.

I dunno -- while it simplifies some use cases, it runs a real risk of making others fairly tricky.  In particular, it makes it very easy to lazily claim a lot of namespace: my casual "Import Foo._" line can wind up causing a lot of subtle name conflicts for everyone who wants to use my library.  Worse, what if Foo has Imports of its own?  The effects could easily multiply, such that my innocuous consumer-level "import" could wind up causing a huge chain of namespace problems that would be a pain to track down and a nuisance to fix.  (With the existing "import" command, it's straightforward to address name conflicts; it looks like they would be significantly more hassle with the indirect version.)

Even that aside, I think the name would definitely be a non-starter.  Putting such an important distinction on a single capital letter (especially one that is hard to distinguish in some fonts) is a bad idea -- way too much semantic weight that is almost invisible to the reader.

I do think that there's some gut-level resistance to the idea, simply because it's extremely counter to a decade+ of Java experience (Scala's "import" is closely related to Java's), but that entirely aside, I honestly think the idea has too much danger to be worth the benefit.  (Especially given that many of the obvious use cases are really just indicators of poorly-encapsulated code -- the Import thing really only makes sense if importing A *always* means you want B as well...)

Kris Nuttycombe schrieb:
> This suggestion brought to mind a different problem that we have
> discussed previously and, in my opinion, not come to a satisfactory
> solution for: the issues of _root_ and how relative imports can cause
> unintended package collisions.
>
> Would it be a reasonable solution to add a keyword to scala that
> serves to indicate that an import is from an absolute root-relative
> path? I know that adding a keyword is something of a drastic solution,
> but
> it might be the cleanest one. Perhaps we could appropriate ruby's "require"?
>
> Kris
>
Well, I like the _root_ for imports, it matches perfectly the root
directory / in the filesystem. A shorthand for _root_ would be cool.

_root_.scala.actors.Actor
would become
.scala.actors.Actor

Similar to filesystem absolute paths /home/andi/scala.

Andi

On Friday March 13 2009, Andreas Hofstadler wrote:
> ...
>
> Well, I like the _root_ for imports, it matches perfectly the root
> directory / in the filesystem. A shorthand for _root_ would be cool.
>
> _root_.scala.actors.Actor
> would become
> .scala.actors.Actor
>
> Similar to filesystem absolute paths /home/andi/scala.

Also similar to the terminal dot (rarely given) in DNS names. (If you don't
know, "www.scala-lang.org", e.g., is the same as "www.scala-lang.org.")

> Andi

Randall Schulz

The suggested feature can certainly be abused, but then so can most other features.

By the way, it just occurred to me that my suggestion would be superflous if "export" also implies "import." In other words, if

export Math._

also imports Math._ into the current scope, then it makes my suggested "Import" irrelevant. That's probably the best solution. Sorry for not realizing that before I started this thread.

Russ P.


On Fri, Mar 13, 2009 at 2:24 PM, Justin du coeur <jducoeur@gmail.com> wrote:

On Fri, Mar 13, 2009 at 4:56 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

If I understand the "export" proposal correctly, I can achieve that in the Mathx object by using

import Math._
export Math._

My "Import" suggestion would replace those two lines with a single line:

Import Math._

This does not do everything that "export" could do, but it would simplify a significant use case.

I dunno -- while it simplifies some use cases, it runs a real risk of making others fairly tricky.  In particular, it makes it very easy to lazily claim a lot of namespace: my casual "Import Foo._" line can wind up causing a lot of subtle name conflicts for everyone who wants to use my library.  Worse, what if Foo has Imports of its own?  The effects could easily multiply, such that my innocuous consumer-level "import" could wind up causing a huge chain of namespace problems that would be a pain to track down and a nuisance to fix.  (With the existing "import" command, it's straightforward to address name conflicts; it looks like they would be significantly more hassle with the indirect version.)

Even that aside, I think the name would definitely be a non-starter.  Putting such an important distinction on a single capital letter (especially one that is hard to distinguish in some fonts) is a bad idea -- way too much semantic weight that is almost invisible to the reader.

I do think that there's some gut-level resistance to the idea, simply because it's extremely counter to a decade+ of Java experience (Scala's "import" is closely related to Java's), but that entirely aside, I honestly think the idea has too much danger to be worth the benefit.  (Especially given that many of the obvious use cases are really just indicators of poorly-encapsulated code -- the Import thing really only makes sense if importing A *always* means you want B as well...)

--
http://RussP.us

As the good Dr. MacIver will testify[1], people don't always notice
differences in case. My suggestion:

export foo.bar

[1] the DR in his nick does not represent doctor. That'd be Dr.

2009/3/13 Russ Paielli :
> On Thu, Mar 12, 2009 at 8:03 PM, Ishaaq Chandy wrote:
>>
>> How is this question not adequately answered by both Jens Alfke and Jon
>> Pretty in their replies to your previous post?
>
>
> I am suggesting a distinction between "import" and "Import." The capitalized
> version would transfer the import over to any module that imports the module
> it appears in.
>
> The earlier replies said that making the current "import" do that would be a
> bad idea. I agree. I am not suggesting that. I am suggesting that both
> alternatives be available.
>
> I am still new to Scala, so I may be naive about this, but I have already
> encountered cases with my own code in which I could have used this
> alternative form of importing. It would simplify my instructions for the
> users of my code because they would only need to import one thing rather
> than two. It's not a critical issue, but I like to make my code as simple as
> possible to use.
>
> The "export" idea is fine, but it is not directly comparable with my
> suggestion. It is more general than what I am suggesting, but it also
> requires another file. It would not make sense to write another file,
> however small, just to eliminate an import line in a file.
>
> Russ P.
>
>>
>> As Jens pointed out, implicit importing as you suggest is
>> dangerous/ambigous and Jon pointed to a viable (possibly viable? I'm no
>> language expert) proposal that would somewhat enable the behaviour you want
>> with the caveat that client classes need to invoke it explicitly, it does
>> not come implicitly.
>>
>> Ishaaq
>>
>> 2009/3/13 Russ Paielli
>>>
>>> On Sun, Feb 1, 2009 at 5:26 PM, Russ Paielli
>>> wrote:
>>>>
>>>> Suppose a module A imports package B, and package B imports package C.
>>>> Shouldn't that be equivalent to module A importing package C also? That's
>>>> what happens in Python, but apparently not in Scala. Am I missing something?
>>>> Is there a way to make it work that way? That would simplify things for the
>>>> client by reducing the number of packages that need to be explicitly
>>>> imported. Thanks.
>>>>
>>>
>>> I'd like to return to this post of mine from a few weeks ago and throw
>>> out an idea. I don't know if it's a good idea or not, but I think it might
>>> have some potential. Why not allow two forms of import, the usual "import,"
>>> and another version called "Import". The capitalized "Import" would
>>> automatically transfer or carry over to any module that imports the package
>>> or class it appears in.
>>>
>>> I don't know if I am typical, but I sometimes want such automatic imports
>>> to simplify matters for the client by reducing the number of imports needed.
>>> "Import" could be a way to achieve that.
>>>
>>> Russ P.
>>
>
>
>
> --
> http://RussP.us
>