Re: package declaration syntax

On Fri, Jan 8, 2010 at 22:53, Stepan Koltsov wrote:
> 2010/1/8 Daniel Sobral :
>> Quite easy:
>>
>> package com.mycompany.wrappers.java.collections
>>
>> import java.io.File // fails, because there's no
>> com.mycompany.wrappers.java.io.File
>
> Why can't "import java.io.File" import both _root_.java.io.File and
> com.mycompany.wrappers.java.io.File ? (successfully if at least one
> exists)

I meant "successfully if exacly one of java.io.File and
com.mycompany.wrappers.java.io.File avaiable".

S.

I could have import java.io._ too. And it might fail because I _have_ a wrappers.java.io package. So it helps some, but it still fails to address the problem that the problem happens unexpectedly. All your hierarchy is imported, whether you want that or not.   The new scheme allows you to _precisely_ specify what you want imported, in a rather simple way. This was not the only proposal ventured -- many solutions were offered, and there was much ado about all of it. This one was simpler, clearer and effective in all situations.   Now, mind you, Having all those packages is rather easy. Here:   package com.mycompany
package department
package project
package module
package subpackage1
package subpackage2
package subpackage3   I typed two things: ^C and ^V. If you do have such a deep hierarchy, then you'll be able cut&paste most of the time, for most of the packages.   Also, if you need to import things from _all_ of that deep hierarchy, your code is probably has some coupling issues. But scala doesn't prevent it anyway.

On Fri, Jan 8, 2010 at 5:53 PM, Stepan Koltsov <yozh@mx1.ru> wrote:

2010/1/8 Daniel Sobral <dcsobral@gmail.com>:
> Quite easy:
>
> package com.mycompany.wrappers.java.collections
>
> import java.io.File // fails, because there's no
> com.mycompany.wrappers.java.io.File

Why can't "import java.io.File" import both _root_.java.io.File and
com.mycompany.wrappers.java.io.File ? (successfully if at least one
exists)

S.


> This is not an hypothetical problem. Big projects out there had problems
> because of it. And it might be, and was, triggered by something as simple as
> one library you depend on being updated.
>
> On Fri, Jan 8, 2010 at 5:40 PM, Stepan Koltsov <yozh@mx1.ru> wrote:
>>
>> Hi,
>>
>> Scala 2.8 got new package declaration semantics. Could someone,
>> please, explain, why the change is necessary?
>>
>> I wrote a test case:
>>
>> === file 1
>> package com.mycompany
>> package scala
>>
>> class X
>> ===
>>
>> === file 2
>> package com.mycompany
>> package app
>>
>> import scala._
>>
>> object O {
>>  val x = new X
>>  val l = List[Int]()
>> }
>> ===
>>
>> It works fine. It means that "import scala._" statement imports both
>> _root_.scala and com.mycompany.scala.
>>
>> So why not make declarations
>>
>> ===
>> package a.b.c.d
>> ===
>>
>> and
>>
>> ===
>> package a
>> package b
>> package c
>> package d
>> ===
>>
>> equivalent?
>>
>> New package declaration semantic is the most annoying change in 2.8,
>> because lots of code need to be rewritten (I use relative imports
>> extensively).
>>
>> And also, I consider new semantics wrong, because in large project
>> every header gets similar header:
>>
>> package com.mycompany
>> package department
>> package project
>> package module
>> package subpackage1
>> package subpackage2
>> package subpackage3
>>
>> Because I relative imports should work relatively all intermediate
>> packages.
>>
>> S.
>
>
>
> --
> Daniel C. Sobral
>
> I travel to the future all the time.
>

--
Daniel C. Sobral

I travel to the future all the time.

2010/1/8 Daniel Sobral :
> I could have import java.io._ too.

It should import everything from both _root_.java.io._ and
com.mycompany.wrappers.java.io._. Symbols exist in both packages
become unavailable unless they are implicitly imported:

===
import java.io._ // File is not available if exist in both
import wrappers.java.io.File // resolve File conflict, if File is required
===

> And it might fail because I _have_ a
> wrappers.java.io package.

import java.io._ imports symbols from io, not io itself, so it won't fail.

>So it helps some, but it still fails to address
> the problem that the problem happens unexpectedly. All your hierarchy is
> imported, whether you want that or not.
>
> The new scheme allows you to _precisely_ specify what you want imported, in
> a rather simple way. This was not the only proposal ventured -- many
> solutions were offered, and there was much ado about all of it. This one was
> simpler, clearer and effective in all situations.
>
> Now, mind you, Having all those packages is rather easy. Here:
>
> package com.mycompany
> package department
> package project
> package module
> package subpackage1
> package subpackage2
> package subpackage3
>
> I typed two things: ^C and ^V. If you do have such a deep hierarchy, then
> you'll be able cut&paste most of the time, for most of the packages.

This is also true for Java. If you think that Java is verbose, you can
use ^C and ^V.

> Also, if you need to import things from _all_ of that deep hierarchy, your
> code is probably has some coupling issues. But scala doesn't prevent it
> anyway.

Well, not each file needs to import everything, but for each package
there is at least one file that needs relative import from that
package. However, similar headers are easier to type (because I use ^C
and ^V), so each file gets the same header.

S.

> On Fri, Jan 8, 2010 at 5:53 PM, Stepan Koltsov wrote:
>>
>> 2010/1/8 Daniel Sobral :
>> > Quite easy:
>> >
>> > package com.mycompany.wrappers.java.collections
>> >
>> > import java.io.File // fails, because there's no
>> > com.mycompany.wrappers.java.io.File
>>
>> Why can't "import java.io.File" import both _root_.java.io.File and
>> com.mycompany.wrappers.java.io.File ? (successfully if at least one
>> exists)
>>
>> S.
>>
>>
>> > This is not an hypothetical problem. Big projects out there had problems
>> > because of it. And it might be, and was, triggered by something as
>> > simple as
>> > one library you depend on being updated.
>> >
>> > On Fri, Jan 8, 2010 at 5:40 PM, Stepan Koltsov wrote:
>> >>
>> >> Hi,
>> >>
>> >> Scala 2.8 got new package declaration semantics. Could someone,
>> >> please, explain, why the change is necessary?
>> >>
>> >> I wrote a test case:
>> >>
>> >> === file 1
>> >> package com.mycompany
>> >> package scala
>> >>
>> >> class X
>> >> ===
>> >>
>> >> === file 2
>> >> package com.mycompany
>> >> package app
>> >>
>> >> import scala._
>> >>
>> >> object O {
>> >>  val x = new X
>> >>  val l = List[Int]()
>> >> }
>> >> ===
>> >>
>> >> It works fine. It means that "import scala._" statement imports both
>> >> _root_.scala and com.mycompany.scala.
>> >>
>> >> So why not make declarations
>> >>
>> >> ===
>> >> package a.b.c.d
>> >> ===
>> >>
>> >> and
>> >>
>> >> ===
>> >> package a
>> >> package b
>> >> package c
>> >> package d
>> >> ===
>> >>
>> >> equivalent?
>> >>
>> >> New package declaration semantic is the most annoying change in 2.8,
>> >> because lots of code need to be rewritten (I use relative imports
>> >> extensively).
>> >>
>> >> And also, I consider new semantics wrong, because in large project
>> >> every header gets similar header:
>> >>
>> >> package com.mycompany
>> >> package department
>> >> package project
>> >> package module
>> >> package subpackage1
>> >> package subpackage2
>> >> package subpackage3
>> >>
>> >> Because I relative imports should work relatively all intermediate
>> >> packages.
>> >>
>> >> S.
>> >
>> >
>> >
>> > --
>> > Daniel C. Sobral
>> >
>> > I travel to the future all the time.
>> >
>
>
>
> --
> Daniel C. Sobral
>
> I travel to the future all the time.
>

So you consider it acceptible that a previously working class becomes
invalid because someone else chooses to duplicate an existing symbol
name under a different package?

On Friday, January 8, 2010, Stepan Koltsov wrote:
> 2010/1/8 Daniel Sobral :
>> I could have import java.io._ too.
>
> It should import everything from both _root_.java.io._ and
> com.mycompany.wrappers.java.io._. Symbols exist in both packages
> become unavailable unless they are implicitly imported:
>
> ===
> import java.io._      // File is not available if exist in both
> import wrappers.java.io.File     // resolve File conflict, if File is required
> ===
>
>> And it might fail because I _have_ a
>> wrappers.java.io package.
>
> import java.io._ imports symbols from io, not io itself, so it won't fail.
>
>
>>So it helps some, but it still fails to address
>> the problem that the problem happens unexpectedly. All your hierarchy is
>> imported, whether you want that or not.
>>
>> The new scheme allows you to _precisely_ specify what you want imported, in
>> a rather simple way. This was not the only proposal ventured -- many
>> solutions were offered, and there was much ado about all of it. This one was
>> simpler, clearer and effective in all situations.
>>
>> Now, mind you, Having all those packages is rather easy. Here:
>>
>> package com.mycompany
>> package department
>> package project
>> package module
>> package subpackage1
>> package subpackage2
>> package subpackage3
>>
>> I typed two things: ^C and ^V. If you do have such a deep hierarchy, then
>> you'll be able cut&paste most of the time, for most of the packages.
>
> This is also true for Java. If you think that Java is verbose, you can
> use ^C and ^V.
>
>
>> Also, if you need to import things from _all_ of that deep hierarchy, your
>> code is probably has some coupling issues. But scala doesn't prevent it
>> anyway.
>
> Well, not each file needs to import everything, but for each package
> there is at least one file that needs relative import from that
> package. However, similar headers are easier to type (because I use ^C
> and ^V), so each file gets the same header.
>
>
> S.
>
>
>> On Fri, Jan 8, 2010 at 5:53 PM, Stepan Koltsov wrote:
>>>
>>> 2010/1/8 Daniel Sobral :
>>> > Quite easy:
>>> >
>>> > package com.mycompany.wrappers.java.collections
>>> >
>>> > import java.io.File // fails, because there's no
>>> > com.mycompany.wrappers.java.io.File
>>>
>>> Why can't "import java.io.File" import both _root_.java.io.File and
>>> com.mycompany.wrappers.java.io.File ? (successfully if at least one
>>> exists)
>>>
>>> S.
>>>
>>>
>>> > This is not an hypothetical problem. Big projects out there had problems
>>> > because of it. And it might be, and was, triggered by something as
>>> > simple as
>>> > one library you depend on being updated.
>>> >
>>> > On Fri, Jan 8, 2010 at 5:40 PM, Stepan Koltsov wrote:
>>> >>
>>> >> Hi,
>>> >>
>>> >> Scala 2.8 got new package declaration semantics. Could someone,
>>> >> please, explain, why the change is necessary?
>>> >>
>>> >> I wrote a test case:
>>> >>
>>> >> === file 1
>>> >> package com.mycompany
>>> >> package scala
>>> >>
>>> >> class X
>>> >> ===
>>> >>
>>> >> === file 2
>>> >> package com.mycompany
>>> >> package app
>>> >>
>>> >> import scala._
>>> >>
>>> >> object O {
>>> >>  val x = new X
>>> >>  val l = List[Int]()
>>> >> }
>>> >> ===
>>> >>
>>> >> It works fine. It means that "import scala._" statement imports both
>>> >> _root_.scala and com.mycompany.scala.
>>> >>
>>> >> So why not make declarations
>>> >>
>>> >> ===
>>> >> package a.b.c.d
>>> >> ===
>>> >>
>>> >> and
>>> >>
>>> >> ===
>>> >> package a
>>> >> package b
>>> >> package c
>>> >> package d
>>> >> ===
>>> >>
>>> >> equivalent?
>>> >>
>>> >> New package declaration semantic is the most annoying change in 2.8,
>>> >> because lots of code need to be rewritten (I use relative imports
>>> >> extensively).
>>> >>
>>> >> And also, I consider new semantics wrong, because in large project
>>> >> every header gets similar header:
>>> >>
>>> >> package com.mycompany
>>> >> package department
>>> >> package project
>>> >> package module
>>> >> package subpackage1
>>> >> package subpackage2
>>> >> package subpackage3
>>> >>
>>> >> Because I relative imports should work relatively all intermediate
>>> >> packages.
>>> >>
>>> >> S.
>>> >
>>> >
>>> >
>>> > --
>>> > Daniel C. Sobral
>>> >
>>> > I travel to the future all the time.
>>> >
>>
>>
>>
>> --
>> Daniel C. Sobral
>>
>> I travel to the future all the time.
>>
>

On Sat, Jan 9, 2010 at 00:17, Kevin Wright
wrote:
> So you consider it acceptible that a previously working class becomes
> invalid because someone else chooses to duplicate an existing symbol
> name under a different package?

If you use import _, and use name defined in both packages, then yes.

There is a lot of situtations when adding something breaks existing
code. For example

import com.mycompany.a._
import com.mycompany.b._

Code will be broken if package b gets new symbol that was already
declared in a. And _any_ package importing scheme does not resolve
this issue.

Another example: you add method to the base class while method with
the same name exists in subclass: code becomes broken: subclass method
must have "override" modifier.

Third example: you add another implicit conversion, and conflict
arises because in some file namespace both implicit conversions become
available because of several import _.

I think the situation you've described is rare, and 2.8 package
importing scheme is overcomplication compared to the scheme I've
described in the first message of this thread.

S.

> On Friday, January 8, 2010, Stepan Koltsov wrote:
>> 2010/1/8 Daniel Sobral :
>>> I could have import java.io._ too.
>>
>> It should import everything from both _root_.java.io._ and
>> com.mycompany.wrappers.java.io._. Symbols exist in both packages
>> become unavailable unless they are implicitly imported:
>>
>> ===
>> import java.io._      // File is not available if exist in both
>> import wrappers.java.io.File     // resolve File conflict, if File is required
>> ===
>>
>>> And it might fail because I _have_ a
>>> wrappers.java.io package.
>>
>> import java.io._ imports symbols from io, not io itself, so it won't fail.
>>
>>
>>>So it helps some, but it still fails to address
>>> the problem that the problem happens unexpectedly. All your hierarchy is
>>> imported, whether you want that or not.
>>>
>>> The new scheme allows you to _precisely_ specify what you want imported, in
>>> a rather simple way. This was not the only proposal ventured -- many
>>> solutions were offered, and there was much ado about all of it. This one was
>>> simpler, clearer and effective in all situations.
>>>
>>> Now, mind you, Having all those packages is rather easy. Here:
>>>
>>> package com.mycompany
>>> package department
>>> package project
>>> package module
>>> package subpackage1
>>> package subpackage2
>>> package subpackage3
>>>
>>> I typed two things: ^C and ^V. If you do have such a deep hierarchy, then
>>> you'll be able cut&paste most of the time, for most of the packages.
>>
>> This is also true for Java. If you think that Java is verbose, you can
>> use ^C and ^V.
>>
>>
>>> Also, if you need to import things from _all_ of that deep hierarchy, your
>>> code is probably has some coupling issues. But scala doesn't prevent it
>>> anyway.
>>
>> Well, not each file needs to import everything, but for each package
>> there is at least one file that needs relative import from that
>> package. However, similar headers are easier to type (because I use ^C
>> and ^V), so each file gets the same header.
>>
>>
>> S.
>>
>>
>>> On Fri, Jan 8, 2010 at 5:53 PM, Stepan Koltsov wrote:
>>>>
>>>> 2010/1/8 Daniel Sobral :
>>>> > Quite easy:
>>>> >
>>>> > package com.mycompany.wrappers.java.collections
>>>> >
>>>> > import java.io.File // fails, because there's no
>>>> > com.mycompany.wrappers.java.io.File
>>>>
>>>> Why can't "import java.io.File" import both _root_.java.io.File and
>>>> com.mycompany.wrappers.java.io.File ? (successfully if at least one
>>>> exists)
>>>>
>>>> S.
>>>>
>>>>
>>>> > This is not an hypothetical problem. Big projects out there had problems
>>>> > because of it. And it might be, and was, triggered by something as
>>>> > simple as
>>>> > one library you depend on being updated.
>>>> >
>>>> > On Fri, Jan 8, 2010 at 5:40 PM, Stepan Koltsov wrote:
>>>> >>
>>>> >> Hi,
>>>> >>
>>>> >> Scala 2.8 got new package declaration semantics. Could someone,
>>>> >> please, explain, why the change is necessary?
>>>> >>
>>>> >> I wrote a test case:
>>>> >>
>>>> >> === file 1
>>>> >> package com.mycompany
>>>> >> package scala
>>>> >>
>>>> >> class X
>>>> >> ===
>>>> >>
>>>> >> === file 2
>>>> >> package com.mycompany
>>>> >> package app
>>>> >>
>>>> >> import scala._
>>>> >>
>>>> >> object O {
>>>> >>  val x = new X
>>>> >>  val l = List[Int]()
>>>> >> }
>>>> >> ===
>>>> >>
>>>> >> It works fine. It means that "import scala._" statement imports both
>>>> >> _root_.scala and com.mycompany.scala.
>>>> >>
>>>> >> So why not make declarations
>>>> >>
>>>> >> ===
>>>> >> package a.b.c.d
>>>> >> ===
>>>> >>
>>>> >> and
>>>> >>
>>>> >> ===
>>>> >> package a
>>>> >> package b
>>>> >> package c
>>>> >> package d
>>>> >> ===
>>>> >>
>>>> >> equivalent?
>>>> >>
>>>> >> New package declaration semantic is the most annoying change in 2.8,
>>>> >> because lots of code need to be rewritten (I use relative imports
>>>> >> extensively).
>>>> >>
>>>> >> And also, I consider new semantics wrong, because in large project
>>>> >> every header gets similar header:
>>>> >>
>>>> >> package com.mycompany
>>>> >> package department
>>>> >> package project
>>>> >> package module
>>>> >> package subpackage1
>>>> >> package subpackage2
>>>> >> package subpackage3
>>>> >>
>>>> >> Because I relative imports should work relatively all intermediate
>>>> >> packages.
>>>> >>
>>>> >> S.
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > Daniel C. Sobral
>>>> >
>>>> > I travel to the future all the time.
>>>> >
>>>
>>>
>>>
>>> --
>>> Daniel C. Sobral
>>>
>>> I travel to the future all the time.
>>>
>>
>
> --
> Kevin Wright
>
> mail/google talk: kev.lee.wright@googlemail.com
> wave: kev.lee.wright@googlewave.com
> skype: kev.lee.wright
> twitter: @thecoda
>

Well, Stepan, don't think the situation is rare, because it is not. The change was provoked by actual instances of code breaking. Arguably, deeply nested packages where one needs the scope of various levels -- and thus can't just use package x.y.z -- are rare.   The choice is, then, between a few extra characters _at the beginning_ of each file, and unpredicatable breakage. I think it is unreasonable to opt for the latter, and you think it is unreasonable to opt for the former.   By the way, I noticed you made a mistake in your first post. You said:   "It means that "import scala._" statement imports both
_root_.scala and com.mycompany.scala."   Which is not true. Only the latter was imported.
On Fri, Jan 8, 2010 at 8:45 PM, Stepan Koltsov <yozh@mx1.ru> wrote:

On Sat, Jan 9, 2010 at 00:17, Kevin Wright
<kev.lee.wright@googlemail.com> wrote:
> So you consider it acceptible that a previously working class becomes
> invalid because someone else chooses to duplicate an existing symbol
> name under a different package?

If you use import _, and use name defined in both packages, then yes.

There is a lot of situtations when adding something breaks existing
code. For example

import com.mycompany.a._
import com.mycompany.b._

Code will be broken if package b gets new symbol that was already
declared in a. And _any_ package importing scheme does not resolve
this issue.

Another example: you add method to the base class while method with
the same name exists in subclass: code becomes broken: subclass method
must have "override" modifier.

Third example: you add another implicit conversion, and conflict
arises because in some file namespace both implicit conversions become
available because of several import _.

I think the situation you've described is rare, and 2.8 package
importing scheme is overcomplication compared to the scheme I've
described in the first message of this thread.

S.


> On Friday, January 8, 2010, Stepan Koltsov <yozh@mx1.ru> wrote:
>> 2010/1/8 Daniel Sobral <dcsobral@gmail.com>:
>>> I could have import java.io._ too.
>>
>> It should import everything from both _root_.java.io._ and
>> com.mycompany.wrappers.java.io._. Symbols exist in both packages
>> become unavailable unless they are implicitly imported:
>>
>> ===
>> import java.io._      // File is not available if exist in both
>> import wrappers.java.io.File     // resolve File conflict, if File is required
>> ===
>>
>>> And it might fail because I _have_ a
>>> wrappers.java.io package.
>>
>> import java.io._ imports symbols from io, not io itself, so it won't fail.
>>
>>
>>>So it helps some, but it still fails to address
>>> the problem that the problem happens unexpectedly. All your hierarchy is
>>> imported, whether you want that or not.
>>>
>>> The new scheme allows you to _precisely_ specify what you want imported, in
>>> a rather simple way. This was not the only proposal ventured -- many
>>> solutions were offered, and there was much ado about all of it. This one was
>>> simpler, clearer and effective in all situations.
>>>
>>> Now, mind you, Having all those packages is rather easy. Here:
>>>
>>> package com.mycompany
>>> package department
>>> package project
>>> package module
>>> package subpackage1
>>> package subpackage2
>>> package subpackage3
>>>
>>> I typed two things: ^C and ^V. If you do have such a deep hierarchy, then
>>> you'll be able cut&paste most of the time, for most of the packages.
>>
>> This is also true for Java. If you think that Java is verbose, you can
>> use ^C and ^V.
>>
>>
>>> Also, if you need to import things from _all_ of that deep hierarchy, your
>>> code is probably has some coupling issues. But scala doesn't prevent it
>>> anyway.
>>
>> Well, not each file needs to import everything, but for each package
>> there is at least one file that needs relative import from that
>> package. However, similar headers are easier to type (because I use ^C
>> and ^V), so each file gets the same header.
>>
>>
>> S.
>>
>>
>>> On Fri, Jan 8, 2010 at 5:53 PM, Stepan Koltsov <yozh@mx1.ru> wrote:
>>>>
>>>> 2010/1/8 Daniel Sobral <dcsobral@gmail.com>:
>>>> > Quite easy:
>>>> >
>>>> > package com.mycompany.wrappers.java.collections
>>>> >
>>>> > import java.io.File // fails, because there's no
>>>> > com.mycompany.wrappers.java.io.File
>>>>
>>>> Why can't "import java.io.File" import both _root_.java.io.File and
>>>> com.mycompany.wrappers.java.io.File ? (successfully if at least one
>>>> exists)
>>>>
>>>> S.
>>>>
>>>>
>>>> > This is not an hypothetical problem. Big projects out there had problems
>>>> > because of it. And it might be, and was, triggered by something as
>>>> > simple as
>>>> > one library you depend on being updated.
>>>> >
>>>> > On Fri, Jan 8, 2010 at 5:40 PM, Stepan Koltsov <yozh@mx1.ru> wrote:
>>>> >>
>>>> >> Hi,
>>>> >>
>>>> >> Scala 2.8 got new package declaration semantics. Could someone,
>>>> >> please, explain, why the change is necessary?
>>>> >>
>>>> >> I wrote a test case:
>>>> >>
>>>> >> === file 1
>>>> >> package com.mycompany
>>>> >> package scala
>>>> >>
>>>> >> class X
>>>> >> ===
>>>> >>
>>>> >> === file 2
>>>> >> package com.mycompany
>>>> >> package app
>>>> >>
>>>> >> import scala._
>>>> >>
>>>> >> object O {
>>>> >>  val x = new X
>>>> >>  val l = List[Int]()
>>>> >> }
>>>> >> ===
>>>> >>
>>>> >> It works fine. It means that "import scala._" statement imports both
>>>> >> _root_.scala and com.mycompany.scala.
>>>> >>
>>>> >> So why not make declarations
>>>> >>
>>>> >> ===
>>>> >> package a.b.c.d
>>>> >> ===
>>>> >>
>>>> >> and
>>>> >>
>>>> >> ===
>>>> >> package a
>>>> >> package b
>>>> >> package c
>>>> >> package d
>>>> >> ===
>>>> >>
>>>> >> equivalent?
>>>> >>
>>>> >> New package declaration semantic is the most annoying change in 2.8,
>>>> >> because lots of code need to be rewritten (I use relative imports
>>>> >> extensively).
>>>> >>
>>>> >> And also, I consider new semantics wrong, because in large project
>>>> >> every header gets similar header:
>>>> >>
>>>> >> package com.mycompany
>>>> >> package department
>>>> >> package project
>>>> >> package module
>>>> >> package subpackage1
>>>> >> package subpackage2
>>>> >> package subpackage3
>>>> >>
>>>> >> Because I relative imports should work relatively all intermediate
>>>> >> packages.
>>>> >>
>>>> >> S.
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > Daniel C. Sobral
>>>> >
>>>> > I travel to the future all the time.
>>>> >
>>>
>>>
>>>
>>> --
>>> Daniel C. Sobral
>>>
>>> I travel to the future all the time.
>>>
>>
>
> --
> Kevin Wright
>
> mail/google talk: kev.lee.wright@googlemail.com
> wave: kev.lee.wright@googlewave.com
> skype: kev.lee.wright
> twitter: @thecoda
>

--
Daniel C. Sobral

I travel to the future all the time.

2010/1/9 Daniel Sobral :
> Well, Stepan, don't think the situation is rare, because it is not. The
> change was provoked by actual instances of code breaking.

With 2.7 problems was frequent, I agreed. I propose a different scheme.

import a.b._

import all symbols from all relative packages that match "a.b". In 2.7
that statement import from subpackage "b" of first "a" package found
in the classpath. That is a problem.

> Arguably, deeply
> nested packages where one needs the scope of various levels -- and thus
> can't just use package x.y.z -- are rare.
>
> The choice is, then, between a few extra characters _at the beginning_ of
> each file, and unpredicatable breakage. I think it is unreasonable to opt
> for the latter, and you think it is unreasonable to opt for the former.
>
> By the way, I noticed you made a mistake in your first post. You said:
>
> "It means that "import scala._" statement imports both
> _root_.scala and com.mycompany.scala."

Yes, sorry.

S.

> Which is not true. Only the latter was imported.
> On Fri, Jan 8, 2010 at 8:45 PM, Stepan Koltsov wrote:
>>
>> On Sat, Jan 9, 2010 at 00:17, Kevin Wright
>> wrote:
>> > So you consider it acceptible that a previously working class becomes
>> > invalid because someone else chooses to duplicate an existing symbol
>> > name under a different package?
>>
>> If you use import _, and use name defined in both packages, then yes.
>>
>> There is a lot of situtations when adding something breaks existing
>> code. For example
>>
>> import com.mycompany.a._
>> import com.mycompany.b._
>>
>> Code will be broken if package b gets new symbol that was already
>> declared in a. And _any_ package importing scheme does not resolve
>> this issue.
>>
>> Another example: you add method to the base class while method with
>> the same name exists in subclass: code becomes broken: subclass method
>> must have "override" modifier.
>>
>> Third example: you add another implicit conversion, and conflict
>> arises because in some file namespace both implicit conversions become
>> available because of several import _.
>>
>> I think the situation you've described is rare, and 2.8 package
>> importing scheme is overcomplication compared to the scheme I've
>> described in the first message of this thread.
>>
>> S.
>>
>>
>> > On Friday, January 8, 2010, Stepan Koltsov wrote:
>> >> 2010/1/8 Daniel Sobral :
>> >>> I could have import java.io._ too.
>> >>
>> >> It should import everything from both _root_.java.io._ and
>> >> com.mycompany.wrappers.java.io._. Symbols exist in both packages
>> >> become unavailable unless they are implicitly imported:
>> >>
>> >> ===
>> >> import java.io._      // File is not available if exist in both
>> >> import wrappers.java.io.File     // resolve File conflict, if File is
>> >> required
>> >> ===
>> >>
>> >>> And it might fail because I _have_ a
>> >>> wrappers.java.io package.
>> >>
>> >> import java.io._ imports symbols from io, not io itself, so it won't
>> >> fail.
>> >>
>> >>
>> >>>So it helps some, but it still fails to address
>> >>> the problem that the problem happens unexpectedly. All your hierarchy
>> >>> is
>> >>> imported, whether you want that or not.
>> >>>
>> >>> The new scheme allows you to _precisely_ specify what you want
>> >>> imported, in
>> >>> a rather simple way. This was not the only proposal ventured -- many
>> >>> solutions were offered, and there was much ado about all of it. This
>> >>> one was
>> >>> simpler, clearer and effective in all situations.
>> >>>
>> >>> Now, mind you, Having all those packages is rather easy. Here:
>> >>>
>> >>> package com.mycompany
>> >>> package department
>> >>> package project
>> >>> package module
>> >>> package subpackage1
>> >>> package subpackage2
>> >>> package subpackage3
>> >>>
>> >>> I typed two things: ^C and ^V. If you do have such a deep hierarchy,
>> >>> then
>> >>> you'll be able cut&paste most of the time, for most of the packages.
>> >>
>> >> This is also true for Java. If you think that Java is verbose, you can
>> >> use ^C and ^V.
>> >>
>> >>
>> >>> Also, if you need to import things from _all_ of that deep hierarchy,
>> >>> your
>> >>> code is probably has some coupling issues. But scala doesn't prevent
>> >>> it
>> >>> anyway.
>> >>
>> >> Well, not each file needs to import everything, but for each package
>> >> there is at least one file that needs relative import from that
>> >> package. However, similar headers are easier to type (because I use ^C
>> >> and ^V), so each file gets the same header.
>> >>
>> >>
>> >> S.
>> >>
>> >>
>> >>> On Fri, Jan 8, 2010 at 5:53 PM, Stepan Koltsov wrote:
>> >>>>
>> >>>> 2010/1/8 Daniel Sobral :
>> >>>> > Quite easy:
>> >>>> >
>> >>>> > package com.mycompany.wrappers.java.collections
>> >>>> >
>> >>>> > import java.io.File // fails, because there's no
>> >>>> > com.mycompany.wrappers.java.io.File
>> >>>>
>> >>>> Why can't "import java.io.File" import both _root_.java.io.File and
>> >>>> com.mycompany.wrappers.java.io.File ? (successfully if at least one
>> >>>> exists)
>> >>>>
>> >>>> S.
>> >>>>
>> >>>>
>> >>>> > This is not an hypothetical problem. Big projects out there had
>> >>>> > problems
>> >>>> > because of it. And it might be, and was, triggered by something as
>> >>>> > simple as
>> >>>> > one library you depend on being updated.
>> >>>> >
>> >>>> > On Fri, Jan 8, 2010 at 5:40 PM, Stepan Koltsov wrote:
>> >>>> >>
>> >>>> >> Hi,
>> >>>> >>
>> >>>> >> Scala 2.8 got new package declaration semantics. Could someone,
>> >>>> >> please, explain, why the change is necessary?
>> >>>> >>
>> >>>> >> I wrote a test case:
>> >>>> >>
>> >>>> >> === file 1
>> >>>> >> package com.mycompany
>> >>>> >> package scala
>> >>>> >>
>> >>>> >> class X
>> >>>> >> ===
>> >>>> >>
>> >>>> >> === file 2
>> >>>> >> package com.mycompany
>> >>>> >> package app
>> >>>> >>
>> >>>> >> import scala._
>> >>>> >>
>> >>>> >> object O {
>> >>>> >>  val x = new X
>> >>>> >>  val l = List[Int]()
>> >>>> >> }
>> >>>> >> ===
>> >>>> >>
>> >>>> >> It works fine. It means that "import scala._" statement imports
>> >>>> >> both
>> >>>> >> _root_.scala and com.mycompany.scala.
>> >>>> >>
>> >>>> >> So why not make declarations
>> >>>> >>
>> >>>> >> ===
>> >>>> >> package a.b.c.d
>> >>>> >> ===
>> >>>> >>
>> >>>> >> and
>> >>>> >>
>> >>>> >> ===
>> >>>> >> package a
>> >>>> >> package b
>> >>>> >> package c
>> >>>> >> package d
>> >>>> >> ===
>> >>>> >>
>> >>>> >> equivalent?
>> >>>> >>
>> >>>> >> New package declaration semantic is the most annoying change in
>> >>>> >> 2.8,
>> >>>> >> because lots of code need to be rewritten (I use relative imports
>> >>>> >> extensively).
>> >>>> >>
>> >>>> >> And also, I consider new semantics wrong, because in large project
>> >>>> >> every header gets similar header:
>> >>>> >>
>> >>>> >> package com.mycompany
>> >>>> >> package department
>> >>>> >> package project
>> >>>> >> package module
>> >>>> >> package subpackage1
>> >>>> >> package subpackage2
>> >>>> >> package subpackage3
>> >>>> >>
>> >>>> >> Because I relative imports should work relatively all intermediate
>> >>>> >> packages.
>> >>>> >>
>> >>>> >> S.
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>> > --
>> >>>> > Daniel C. Sobral
>> >>>> >
>> >>>> > I travel to the future all the time.
>> >>>> >
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Daniel C. Sobral
>> >>>
>> >>> I travel to the future all the time.
>> >>>
>> >>
>> >
>> > --
>> > Kevin Wright
>> >
>> > mail/google talk: kev.lee.wright@googlemail.com
>> > wave: kev.lee.wright@googlewave.com
>> > skype: kev.lee.wright
>> > twitter: @thecoda
>> >
>
>
>
> --
> Daniel C. Sobral
>
> I travel to the future all the time.
>

what if you thought you were importing com.myco.wrappers.java.io.File (but
you had not finished the implementation)? in your scenario java.io.File
would be pulled into scope with no warning or error. A subtle bug is then
introduced.

What might be nice is for Martin to save our poor fingers and eyes from
having "_root_" noise up our code, by allowing "_" to be a placeholder for
"_root_" at the beginning of import path.

"import _.java.io.File" would imply "import _root_.java.io.File"

and

"import _.java.io._" would imply "import _root_.java.io._"

> Why can't "import java.io.File" import both _root_.java.io.File and
> com.mycompany.wrappers.java.io.File ? (successfully if at least one
> exists)

I meant "successfully if exacly one of java.io.File and
com.mycompany.wrappers.java.io.File avaiable".

S.

On Sun, Jan 10, 2010 at 05:17, jherber wrote:
>
> what if you thought you were importing com.myco.wrappers.java.io.File (but
> you had not finished the implementation)?  in your scenario java.io.File
> would be pulled into scope with no warning or error.  A subtle bug is then
> introduced.

I said, if both classes match "import java.io.File", no class should
be imported. Attempt to use File identifier should be an error.

Anyway, having several classes with same name in single project is a
bad idea. AFAIU, intent of new package importing mechanism is to
protect against duplicate package names, not against duplicate class
names.

I don't understand, why new verbose package declaration syntax (that
also breaks existing code) does not annoy people. Why doesn't everyone
complain? Maybe I miss something...

S.

> What might be nice is for Martin to save our poor fingers and eyes from
> having "_root_" noise up our code, by allowing "_" to be a placeholder for
> "_root_" at the beginning of import path.
>
> "import _.java.io.File" would imply "import _root_.java.io.File"
>
> and
>
> "import _.java.io._" would imply "import _root_.java.io._"
>
>
>
>
>> Why can't "import java.io.File" import both _root_.java.io.File and
>> com.mycompany.wrappers.java.io.File ? (successfully if at least one
>> exists)
>
> I meant "successfully if exacly one of java.io.File and
> com.mycompany.wrappers.java.io.File avaiable".
>
> S.
>
>
>
> --
> View this message in context: http://old.nabble.com/package-declaration-syntax-tp27081262p27095040.html
> Sent from the Scala - User mailing list archive at Nabble.com.
>
>

Did you search for the discussion? This was all discussed very openly at length, quite a while ago. After you read the discussion if you have questions ask them, although it's probably too late.

-------------------------------------
Stepan Koltsov wrote:

On Sun, Jan 10, 2010 at 05:17, jherber wrote:
>
> what if you thought you were importing com.myco.wrappers.java.io.File (but
> you had not finished the implementation)?  in your scenario java.io.File
> would be pulled into scope with no warning or error.  A subtle bug is then
> introduced.

I said, if both classes match "import java.io.File", no class should
be imported. Attempt to use File identifier should be an error.

Anyway, having several classes with same name in single project is a
bad idea. AFAIU, intent of new package importing mechanism is to
protect against duplicate package names, not against duplicate class
names.

I don't understand, why new verbose package declaration syntax (that
also breaks existing code) does not annoy people. Why doesn't everyone
complain? Maybe I miss something...

S.

> What might be nice is for Martin to save our poor fingers and eyes from
> having "_root_" noise up our code, by allowing "_" to be a placeholder for
> "_root_" at the beginning of import path.
>
> "import _.java.io.File" would imply "import _root_.java.io.File"
>
> and
>
> "import _.java.io._" would imply "import _root_.java.io._"
>
>
>
>
>> Why can't "import java.io.File" import both _root_.java.io.File and
>> com.mycompany.wrappers.java.io.File ? (successfully if at least one
>> exists)
>
> I meant "successfully if exacly one of java.io.File and
> com.mycompany.wrappers.java.io.File avaiable".
>
> S.
>
>
>
> --
> View this message in context: http://old.nabble.com/package-declaration-syntax-tp27081262p27095040.html
> Sent from the Scala - User mailing list archive at Nabble.com.
>
>

On Sun, Jan 10, 2010 at 05:58, Naftoli Gugenheim wrote:
> Did you search for the discussion? This was all discussed very openly at length, quite a while ago. After you read the discussion if you have questions ask them, although it's probably too late.

No, it is not too late, 2.8 even is not beta yet.

I searched (now), I have found several discussions where 2.7 package
importing mechanism compared to 2.8 mechanism.

I haven't found a discussion of what I'd like to have: "import a.b.C"
statement imports from (maybe) several packages.

S.

> -------------------------------------
> Stepan Koltsov wrote:
>
> On Sun, Jan 10, 2010 at 05:17, jherber wrote:
>>
>> what if you thought you were importing com.myco.wrappers.java.io.File (but
>> you had not finished the implementation)?  in your scenario java.io.File
>> would be pulled into scope with no warning or error.  A subtle bug is then
>> introduced.
>
> I said, if both classes match "import java.io.File", no class should
> be imported. Attempt to use File identifier should be an error.
>
> Anyway, having several classes with same name in single project is a
> bad idea. AFAIU, intent of new package importing mechanism is to
> protect against duplicate package names, not against duplicate class
> names.
>
> I don't understand, why new verbose package declaration syntax (that
> also breaks existing code) does not annoy people. Why doesn't everyone
> complain? Maybe I miss something...
>
> S.
>
>
>> What might be nice is for Martin to save our poor fingers and eyes from
>> having "_root_" noise up our code, by allowing "_" to be a placeholder for
>> "_root_" at the beginning of import path.
>>
>> "import _.java.io.File" would imply "import _root_.java.io.File"
>>
>> and
>>
>> "import _.java.io._" would imply "import _root_.java.io._"
>>
>>
>>
>>
>>> Why can't "import java.io.File" import both _root_.java.io.File and
>>> com.mycompany.wrappers.java.io.File ? (successfully if at least one
>>> exists)
>>
>> I meant "successfully if exacly one of java.io.File and
>> com.mycompany.wrappers.java.io.File avaiable".
>>
>> S.
>>
>>
>>
>> --
>> View this message in context: http://old.nabble.com/package-declaration-syntax-tp27081262p27095040.html
>> Sent from the Scala - User mailing list archive at Nabble.com.
>>
>>
>

On Sun, Jan 10, 2010 at 06:31, Naftoli Gugenheim wrote:
> Maybe someone can link to the right thread?

You meant there was a thread? And similar proposal was rejected?

S.

> -------------------------------------
> Stepan Koltsov wrote:
>
> On Sun, Jan 10, 2010 at 05:58, Naftoli Gugenheim wrote:
>> Did you search for the discussion? This was all discussed very openly at length, quite a while ago. After you read the discussion if you have questions ask them, although it's probably too late.
>
> No, it is not too late, 2.8 even is not beta yet.
>
> I searched (now), I have found several discussions where 2.7 package
> importing mechanism compared to 2.8 mechanism.
>
> I haven't found a discussion of what I'd like to have: "import a.b.C"
> statement imports from (maybe) several packages.
>
> S.
>
>
>> -------------------------------------
>> Stepan Koltsov wrote:
>>
>> On Sun, Jan 10, 2010 at 05:17, jherber wrote:
>>>
>>> what if you thought you were importing com.myco.wrappers.java.io.File (but
>>> you had not finished the implementation)?  in your scenario java.io.File
>>> would be pulled into scope with no warning or error.  A subtle bug is then
>>> introduced.
>>
>> I said, if both classes match "import java.io.File", no class should
>> be imported. Attempt to use File identifier should be an error.
>>
>> Anyway, having several classes with same name in single project is a
>> bad idea. AFAIU, intent of new package importing mechanism is to
>> protect against duplicate package names, not against duplicate class
>> names.
>>
>> I don't understand, why new verbose package declaration syntax (that
>> also breaks existing code) does not annoy people. Why doesn't everyone
>> complain? Maybe I miss something...
>>
>> S.
>>
>>
>>> What might be nice is for Martin to save our poor fingers and eyes from
>>> having "_root_" noise up our code, by allowing "_" to be a placeholder for
>>> "_root_" at the beginning of import path.
>>>
>>> "import _.java.io.File" would imply "import _root_.java.io.File"
>>>
>>> and
>>>
>>> "import _.java.io._" would imply "import _root_.java.io._"
>>>
>>>
>>>
>>>
>>>> Why can't "import java.io.File" import both _root_.java.io.File and
>>>> com.mycompany.wrappers.java.io.File ? (successfully if at least one
>>>> exists)
>>>
>>> I meant "successfully if exacly one of java.io.File and
>>> com.mycompany.wrappers.java.io.File avaiable".
>>>
>>> S.
>>>
>>>
>>>
>>> --
>>> View this message in context: http://old.nabble.com/package-declaration-syntax-tp27081262p27095040.html
>>> Sent from the Scala - User mailing list archive at Nabble.com.
>>>
>>>
>>
>

I believe so, but not promising.

-------------------------------------
Stepan Koltsov wrote:

On Sun, Jan 10, 2010 at 06:31, Naftoli Gugenheim wrote:
> Maybe someone can link to the right thread?

You meant there was a thread? And similar proposal was rejected?

S.

> -------------------------------------
> Stepan Koltsov wrote:
>
> On Sun, Jan 10, 2010 at 05:58, Naftoli Gugenheim wrote:
>> Did you search for the discussion? This was all discussed very openly at length, quite a while ago. After you read the discussion if you have questions ask them, although it's probably too late.
>
> No, it is not too late, 2.8 even is not beta yet.
>
> I searched (now), I have found several discussions where 2.7 package
> importing mechanism compared to 2.8 mechanism.
>
> I haven't found a discussion of what I'd like to have: "import a.b.C"
> statement imports from (maybe) several packages.
>
> S.
>
>
>> -------------------------------------
>> Stepan Koltsov wrote:
>>
>> On Sun, Jan 10, 2010 at 05:17, jherber wrote:
>>>
>>> what if you thought you were importing com.myco.wrappers.java.io.File (but
>>> you had not finished the implementation)?  in your scenario java.io.File
>>> would be pulled into scope with no warning or error.  A subtle bug is then
>>> introduced.
>>
>> I said, if both classes match "import java.io.File", no class should
>> be imported. Attempt to use File identifier should be an error.
>>
>> Anyway, having several classes with same name in single project is a
>> bad idea. AFAIU, intent of new package importing mechanism is to
>> protect against duplicate package names, not against duplicate class
>> names.
>>
>> I don't understand, why new verbose package declaration syntax (that
>> also breaks existing code) does not annoy people. Why doesn't everyone
>> complain? Maybe I miss something...
>>
>> S.
>>
>>
>>> What might be nice is for Martin to save our poor fingers and eyes from
>>> having "_root_" noise up our code, by allowing "_" to be a placeholder for
>>> "_root_" at the beginning of import path.
>>>
>>> "import _.java.io.File" would imply "import _root_.java.io.File"
>>>
>>> and
>>>
>>> "import _.java.io._" would imply "import _root_.java.io._"
>>>
>>>
>>>
>>>
>>>> Why can't "import java.io.File" import both _root_.java.io.File and
>>>> com.mycompany.wrappers.java.io.File ? (successfully if at least one
>>>> exists)
>>>
>>> I meant "successfully if exacly one of java.io.File and
>>> com.mycompany.wrappers.java.io.File avaiable".
>>>
>>> S.
>>>
>>>
>>>
>>> --
>>> View this message in context: http://old.nabble.com/package-declaration-syntax-tp27081262p27095040.html
>>> Sent from the Scala - User mailing list archive at Nabble.com.
>>>
>>>
>>
>

Maybe someone can link to the right thread?

-------------------------------------
Stepan Koltsov wrote:

On Sun, Jan 10, 2010 at 05:58, Naftoli Gugenheim wrote:
> Did you search for the discussion? This was all discussed very openly at length, quite a while ago. After you read the discussion if you have questions ask them, although it's probably too late.

No, it is not too late, 2.8 even is not beta yet.

I searched (now), I have found several discussions where 2.7 package
importing mechanism compared to 2.8 mechanism.

I haven't found a discussion of what I'd like to have: "import a.b.C"
statement imports from (maybe) several packages.

S.

> -------------------------------------
> Stepan Koltsov wrote:
>
> On Sun, Jan 10, 2010 at 05:17, jherber wrote:
>>
>> what if you thought you were importing com.myco.wrappers.java.io.File (but
>> you had not finished the implementation)?  in your scenario java.io.File
>> would be pulled into scope with no warning or error.  A subtle bug is then
>> introduced.
>
> I said, if both classes match "import java.io.File", no class should
> be imported. Attempt to use File identifier should be an error.
>
> Anyway, having several classes with same name in single project is a
> bad idea. AFAIU, intent of new package importing mechanism is to
> protect against duplicate package names, not against duplicate class
> names.
>
> I don't understand, why new verbose package declaration syntax (that
> also breaks existing code) does not annoy people. Why doesn't everyone
> complain? Maybe I miss something...
>
> S.
>
>
>> What might be nice is for Martin to save our poor fingers and eyes from
>> having "_root_" noise up our code, by allowing "_" to be a placeholder for
>> "_root_" at the beginning of import path.
>>
>> "import _.java.io.File" would imply "import _root_.java.io.File"
>>
>> and
>>
>> "import _.java.io._" would imply "import _root_.java.io._"
>>
>>
>>
>>
>>> Why can't "import java.io.File" import both _root_.java.io.File and
>>> com.mycompany.wrappers.java.io.File ? (successfully if at least one
>>> exists)
>>
>> I meant "successfully if exacly one of java.io.File and
>> com.mycompany.wrappers.java.io.File avaiable".
>>
>> S.
>>
>>
>>
>> --
>> View this message in context: http://old.nabble.com/package-declaration-syntax-tp27081262p27095040.html
>> Sent from the Scala - User mailing list archive at Nabble.com.
>>
>>
>

It was a long one, and included Martin Odersky, so that should narrow it down.

-------------------------------------
Stepan Koltsov wrote:

On Sun, Jan 10, 2010 at 06:31, Naftoli Gugenheim wrote:
> Maybe someone can link to the right thread?

You meant there was a thread? And similar proposal was rejected?

S.

> -------------------------------------
> Stepan Koltsov wrote:
>
> On Sun, Jan 10, 2010 at 05:58, Naftoli Gugenheim wrote:
>> Did you search for the discussion? This was all discussed very openly at length, quite a while ago. After you read the discussion if you have questions ask them, although it's probably too late.
>
> No, it is not too late, 2.8 even is not beta yet.
>
> I searched (now), I have found several discussions where 2.7 package
> importing mechanism compared to 2.8 mechanism.
>
> I haven't found a discussion of what I'd like to have: "import a.b.C"
> statement imports from (maybe) several packages.
>
> S.
>
>
>> -------------------------------------
>> Stepan Koltsov wrote:
>>
>> On Sun, Jan 10, 2010 at 05:17, jherber wrote:
>>>
>>> what if you thought you were importing com.myco.wrappers.java.io.File (but
>>> you had not finished the implementation)?  in your scenario java.io.File
>>> would be pulled into scope with no warning or error.  A subtle bug is then
>>> introduced.
>>
>> I said, if both classes match "import java.io.File", no class should
>> be imported. Attempt to use File identifier should be an error.
>>
>> Anyway, having several classes with same name in single project is a
>> bad idea. AFAIU, intent of new package importing mechanism is to
>> protect against duplicate package names, not against duplicate class
>> names.
>>
>> I don't understand, why new verbose package declaration syntax (that
>> also breaks existing code) does not annoy people. Why doesn't everyone
>> complain? Maybe I miss something...
>>
>> S.
>>
>>
>>> What might be nice is for Martin to save our poor fingers and eyes from
>>> having "_root_" noise up our code, by allowing "_" to be a placeholder for
>>> "_root_" at the beginning of import path.
>>>
>>> "import _.java.io.File" would imply "import _root_.java.io.File"
>>>
>>> and
>>>
>>> "import _.java.io._" would imply "import _root_.java.io._"
>>>
>>>
>>>
>>>
>>>> Why can't "import java.io.File" import both _root_.java.io.File and
>>>> com.mycompany.wrappers.java.io.File ? (successfully if at least one
>>>> exists)
>>>
>>> I meant "successfully if exacly one of java.io.File and
>>> com.mycompany.wrappers.java.io.File avaiable".
>>>
>>> S.
>>>
>>>
>>>
>>> --
>>> View this message in context: http://old.nabble.com/package-declaration-syntax-tp27081262p27095040.html
>>> Sent from the Scala - User mailing list archive at Nabble.com.
>>>
>>>
>>
>

http://old.nabble.com/Revisiting-absolute-relative-paths-to24492690.html
http://old.nabble.com/Nested-package-scopes-vs.-Imports-%28Was%3A-Revisi...

On Sun, Jan 10, 2010 at 4:37 AM, Naftoli Gugenheim wrote:
> It was a long one, and included Martin Odersky, so that should narrow it down.
>
> -------------------------------------
> Stepan Koltsov wrote:
>
> On Sun, Jan 10, 2010 at 06:31, Naftoli Gugenheim wrote:
>> Maybe someone can link to the right thread?
>
> You meant there was a thread? And similar proposal was rejected?
>
> S.
>
>
>> -------------------------------------
>> Stepan Koltsov wrote:
>>
>> On Sun, Jan 10, 2010 at 05:58, Naftoli Gugenheim wrote:
>>> Did you search for the discussion? This was all discussed very openly at length, quite a while ago. After you read the discussion if you have questions ask them, although it's probably too late.
>>
>> No, it is not too late, 2.8 even is not beta yet.
>>
>> I searched (now), I have found several discussions where 2.7 package
>> importing mechanism compared to 2.8 mechanism.
>>
>> I haven't found a discussion of what I'd like to have: "import a.b.C"
>> statement imports from (maybe) several packages.
>>
>> S.
>>
>>
>>> -------------------------------------
>>> Stepan Koltsov wrote:
>>>
>>> On Sun, Jan 10, 2010 at 05:17, jherber wrote:
>>>>
>>>> what if you thought you were importing com.myco.wrappers.java.io.File (but
>>>> you had not finished the implementation)?  in your scenario java.io.File
>>>> would be pulled into scope with no warning or error.  A subtle bug is then
>>>> introduced.
>>>
>>> I said, if both classes match "import java.io.File", no class should
>>> be imported. Attempt to use File identifier should be an error.
>>>
>>> Anyway, having several classes with same name in single project is a
>>> bad idea. AFAIU, intent of new package importing mechanism is to
>>> protect against duplicate package names, not against duplicate class
>>> names.
>>>
>>> I don't understand, why new verbose package declaration syntax (that
>>> also breaks existing code) does not annoy people. Why doesn't everyone
>>> complain? Maybe I miss something...
>>>
>>> S.
>>>
>>>
>>>> What might be nice is for Martin to save our poor fingers and eyes from
>>>> having "_root_" noise up our code, by allowing "_" to be a placeholder for
>>>> "_root_" at the beginning of import path.
>>>>
>>>> "import _.java.io.File" would imply "import _root_.java.io.File"
>>>>
>>>> and
>>>>
>>>> "import _.java.io._" would imply "import _root_.java.io._"
>>>>
>>>>
>>>>
>>>>
>>>>> Why can't "import java.io.File" import both _root_.java.io.File and
>>>>> com.mycompany.wrappers.java.io.File ? (successfully if at least one
>>>>> exists)
>>>>
>>>> I meant "successfully if exacly one of java.io.File and
>>>> com.mycompany.wrappers.java.io.File avaiable".
>>>>
>>>> S.
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context: http://old.nabble.com/package-declaration-syntax-tp27081262p27095040.html
>>>> Sent from the Scala - User mailing list archive at Nabble.com.
>>>>
>>>>
>>>
>>
>

Thanks. Often knowing why, and why not is helpful in remembering these edge
cases, and explaining them to others.

Johannes Rudolph-2 wrote:
>
> http://old.nabble.com/Revisiting-absolute-relative-paths-to24492690.html
> http://old.nabble.com/Nested-package-scopes-vs.-Imports-%28Was%3A-Revisi...
>
> On Sun, Jan 10, 2010 at 4:37 AM, Naftoli Gugenheim
> wrote:
>> It was a long one, and included Martin Odersky, so that should narrow it
>> down.
>>
>> -------------------------------------
>> Stepan Koltsov wrote:
>>
>> On Sun, Jan 10, 2010 at 06:31, Naftoli Gugenheim
>> wrote:
>>> Maybe someone can link to the right thread?
>>
>> You meant there was a thread? And similar proposal was rejected?
>>
>> S.
>>
>>
>>> -------------------------------------
>>> Stepan Koltsov wrote:
>>>
>>> On Sun, Jan 10, 2010 at 05:58, Naftoli Gugenheim
>>> wrote:
>>>> Did you search for the discussion? This was all discussed very openly
>>>> at length, quite a while ago. After you read the discussion if you have
>>>> questions ask them, although it's probably too late.
>>>
>>> No, it is not too late, 2.8 even is not beta yet.
>>>
>>> I searched (now), I have found several discussions where 2.7 package
>>> importing mechanism compared to 2.8 mechanism.
>>>
>>> I haven't found a discussion of what I'd like to have: "import a.b.C"
>>> statement imports from (maybe) several packages.
>>>
>>> S.
>>>
>>>
>>>> -------------------------------------
>>>> Stepan Koltsov wrote:
>>>>
>>>> On Sun, Jan 10, 2010 at 05:17, jherber wrote:
>>>>>
>>>>> what if you thought you were importing com.myco.wrappers.java.io.File
>>>>> (but
>>>>> you had not finished the implementation)?  in your scenario
>>>>> java.io.File
>>>>> would be pulled into scope with no warning or error.  A subtle bug is
>>>>> then
>>>>> introduced.
>>>>
>>>> I said, if both classes match "import java.io.File", no class should
>>>> be imported. Attempt to use File identifier should be an error.
>>>>
>>>> Anyway, having several classes with same name in single project is a
>>>> bad idea. AFAIU, intent of new package importing mechanism is to
>>>> protect against duplicate package names, not against duplicate class
>>>> names.
>>>>
>>>> I don't understand, why new verbose package declaration syntax (that
>>>> also breaks existing code) does not annoy people. Why doesn't everyone
>>>> complain? Maybe I miss something...
>>>>
>>>> S.
>>>>
>>>>
>>>>> What might be nice is for Martin to save our poor fingers and eyes
>>>>> from
>>>>> having "_root_" noise up our code, by allowing "_" to be a placeholder
>>>>> for
>>>>> "_root_" at the beginning of import path.
>>>>>
>>>>> "import _.java.io.File" would imply "import _root_.java.io.File"
>>>>>
>>>>> and
>>>>>
>>>>> "import _.java.io._" would imply "import _root_.java.io._"
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Why can't "import java.io.File" import both _root_.java.io.File and
>>>>>> com.mycompany.wrappers.java.io.File ? (successfully if at least one
>>>>>> exists)
>>>>>
>>>>> I meant "successfully if exacly one of java.io.File and
>>>>> com.mycompany.wrappers.java.io.File avaiable".
>>>>>
>>>>> S.
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>> http://old.nabble.com/package-declaration-syntax-tp27081262p27095040.html
>>>>> Sent from the Scala - User mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>
>>>
>>
>
>
>

On Sun, Jan 10, 2010 at 13:18, Johannes Rudolph
wrote:
> http://old.nabble.com/Revisiting-absolute-relative-paths-to24492690.html
> http://old.nabble.com/Nested-package-scopes-vs.-Imports-%28Was%3A-Revisi...

Neither link discusses what I want: "import a.b.C" imports C from one
of _root_.a.b, com.a.b, com.mycompany.a.b, com.mycompany.program.a.b
if only one exists.

S.

> On Sun, Jan 10, 2010 at 4:37 AM, Naftoli Gugenheim wrote:
>> It was a long one, and included Martin Odersky, so that should narrow it down.
>>
>> -------------------------------------
>> Stepan Koltsov wrote:
>>
>> On Sun, Jan 10, 2010 at 06:31, Naftoli Gugenheim wrote:
>>> Maybe someone can link to the right thread?
>>
>> You meant there was a thread? And similar proposal was rejected?
>>
>> S.
>>
>>
>>> -------------------------------------
>>> Stepan Koltsov wrote:
>>>
>>> On Sun, Jan 10, 2010 at 05:58, Naftoli Gugenheim wrote:
>>>> Did you search for the discussion? This was all discussed very openly at length, quite a while ago. After you read the discussion if you have questions ask them, although it's probably too late.
>>>
>>> No, it is not too late, 2.8 even is not beta yet.
>>>
>>> I searched (now), I have found several discussions where 2.7 package
>>> importing mechanism compared to 2.8 mechanism.
>>>
>>> I haven't found a discussion of what I'd like to have: "import a.b.C"
>>> statement imports from (maybe) several packages.
>>>
>>> S.
>>>
>>>
>>>> -------------------------------------
>>>> Stepan Koltsov wrote:
>>>>
>>>> On Sun, Jan 10, 2010 at 05:17, jherber wrote:
>>>>>
>>>>> what if you thought you were importing com.myco.wrappers.java.io.File (but
>>>>> you had not finished the implementation)?  in your scenario java.io.File
>>>>> would be pulled into scope with no warning or error.  A subtle bug is then
>>>>> introduced.
>>>>
>>>> I said, if both classes match "import java.io.File", no class should
>>>> be imported. Attempt to use File identifier should be an error.
>>>>
>>>> Anyway, having several classes with same name in single project is a
>>>> bad idea. AFAIU, intent of new package importing mechanism is to
>>>> protect against duplicate package names, not against duplicate class
>>>> names.
>>>>
>>>> I don't understand, why new verbose package declaration syntax (that
>>>> also breaks existing code) does not annoy people. Why doesn't everyone
>>>> complain? Maybe I miss something...
>>>>
>>>> S.
>>>>
>>>>
>>>>> What might be nice is for Martin to save our poor fingers and eyes from
>>>>> having "_root_" noise up our code, by allowing "_" to be a placeholder for
>>>>> "_root_" at the beginning of import path.
>>>>>
>>>>> "import _.java.io.File" would imply "import _root_.java.io.File"
>>>>>
>>>>> and
>>>>>
>>>>> "import _.java.io._" would imply "import _root_.java.io._"
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Why can't "import java.io.File" import both _root_.java.io.File and
>>>>>> com.mycompany.wrappers.java.io.File ? (successfully if at least one
>>>>>> exists)
>>>>>
>>>>> I meant "successfully if exacly one of java.io.File and
>>>>> com.mycompany.wrappers.java.io.File avaiable".
>>>>>
>>>>> S.
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> View this message in context: http://old.nabble.com/package-declaration-syntax-tp27081262p27095040.html
>>>>> Sent from the Scala - User mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>
>>>
>>
>
>
>
> --
> Johannes
>
> -----------------------------------------------
> Johannes Rudolph
> http://virtual-void.net
>

And how would you go about avoiding importing more than you want?

On Sun, Jan 10, 2010 at 2:21 PM, Stepan Koltsov <stepan.koltsov@gmail.com> wrote:

On Sun, Jan 10, 2010 at 13:18, Johannes Rudolph
<johannes.rudolph@googlemail.com> wrote:
> http://old.nabble.com/Revisiting-absolute-relative-paths-to24492690.html
> http://old.nabble.com/Nested-package-scopes-vs.-Imports-%28Was%3A-Revisiting--absolute-relative-paths%29-tp24517644p24518578.html

Neither link discusses what I want: "import a.b.C" imports C from one
of _root_.a.b, com.a.b, com.mycompany.a.b, com.mycompany.program.a.b
if only one exists.

S.


> On Sun, Jan 10, 2010 at 4:37 AM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:
>> It was a long one, and included Martin Odersky, so that should narrow it down.
>>
>> -------------------------------------
>> Stepan Koltsov<stepan.koltsov@gmail.com> wrote:
>>
>> On Sun, Jan 10, 2010 at 06:31, Naftoli Gugenheim <naftoligug@gmail.com> wrote:
>>> Maybe someone can link to the right thread?
>>
>> You meant there was a thread? And similar proposal was rejected?
>>
>> S.
>>
>>
>>> -------------------------------------
>>> Stepan Koltsov<stepan.koltsov@gmail.com> wrote:
>>>
>>> On Sun, Jan 10, 2010 at 05:58, Naftoli Gugenheim <naftoligug@gmail.com> wrote:
>>>> Did you search for the discussion? This was all discussed very openly at length, quite a while ago. After you read the discussion if you have questions ask them, although it's probably too late.
>>>
>>> No, it is not too late, 2.8 even is not beta yet.
>>>
>>> I searched (now), I have found several discussions where 2.7 package
>>> importing mechanism compared to 2.8 mechanism.
>>>
>>> I haven't found a discussion of what I'd like to have: "import a.b.C"
>>> statement imports from (maybe) several packages.
>>>
>>> S.
>>>
>>>
>>>> -------------------------------------
>>>> Stepan Koltsov<stepan.koltsov@gmail.com> wrote:
>>>>
>>>> On Sun, Jan 10, 2010 at 05:17, jherber <jimherber@gmail.com> wrote:
>>>>>
>>>>> what if you thought you were importing com.myco.wrappers.java.io.File (but
>>>>> you had not finished the implementation)?  in your scenario java.io.File
>>>>> would be pulled into scope with no warning or error.  A subtle bug is then
>>>>> introduced.
>>>>
>>>> I said, if both classes match "import java.io.File", no class should
>>>> be imported. Attempt to use File identifier should be an error.
>>>>
>>>> Anyway, having several classes with same name in single project is a
>>>> bad idea. AFAIU, intent of new package importing mechanism is to
>>>> protect against duplicate package names, not against duplicate class
>>>> names.
>>>>
>>>> I don't understand, why new verbose package declaration syntax (that
>>>> also breaks existing code) does not annoy people. Why doesn't everyone
>>>> complain? Maybe I miss something...
>>>>
>>>> S.
>>>>
>>>>
>>>>> What might be nice is for Martin to save our poor fingers and eyes from
>>>>> having "_root_" noise up our code, by allowing "_" to be a placeholder for
>>>>> "_root_" at the beginning of import path.
>>>>>
>>>>> "import _.java.io.File" would imply "import _root_.java.io.File"
>>>>>
>>>>> and
>>>>>
>>>>> "import _.java.io._" would imply "import _root_.java.io._"
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Why can't "import java.io.File" import both _root_.java.io.File and
>>>>>> com.mycompany.wrappers.java.io.File ? (successfully if at least one
>>>>>> exists)
>>>>>
>>>>> I meant "successfully if exacly one of java.io.File and
>>>>> com.mycompany.wrappers.java.io.File avaiable".
>>>>>
>>>>> S.
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> View this message in context: http://old.nabble.com/package-declaration-syntax-tp27081262p27095040.html
>>>>> Sent from the Scala - User mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>
>>>
>>
>
>
>
> --
> Johannes
>
> -----------------------------------------------
> Johannes Rudolph
> http://virtual-void.net
>

--
Daniel C. Sobral

I travel to the future all the time.

On Sun, Jan 10, 2010 at 19:42, Daniel Sobral wrote:
> And how would you go about avoiding importing more than you want?

import _root_.a.b.C imports only _root_.a.b.C

import mycompany.a.b.C imports only _root_.com.mycompany.a.b.C

But precise import is rarely needed, because duplicate class names are
rare (unlike duplicate package names).

S.

> On Sun, Jan 10, 2010 at 2:21 PM, Stepan Koltsov
> wrote:
>>
>> On Sun, Jan 10, 2010 at 13:18, Johannes Rudolph
>> wrote:
>> > http://old.nabble.com/Revisiting-absolute-relative-paths-to24492690.html
>> >
>> > http://old.nabble.com/Nested-package-scopes-vs.-Imports-%28Was%3A-Revisi...
>>
>> Neither link discusses what I want: "import a.b.C" imports C from one
>> of _root_.a.b, com.a.b, com.mycompany.a.b, com.mycompany.program.a.b
>> if only one exists.
>>
>> S.
>>
>>
>> > On Sun, Jan 10, 2010 at 4:37 AM, Naftoli Gugenheim
>> > wrote:
>> >> It was a long one, and included Martin Odersky, so that should narrow
>> >> it down.
>> >>
>> >> -------------------------------------
>> >> Stepan Koltsov wrote:
>> >>
>> >> On Sun, Jan 10, 2010 at 06:31, Naftoli Gugenheim
>> >> wrote:
>> >>> Maybe someone can link to the right thread?
>> >>
>> >> You meant there was a thread? And similar proposal was rejected?
>> >>
>> >> S.
>> >>
>> >>
>> >>> -------------------------------------
>> >>> Stepan Koltsov wrote:
>> >>>
>> >>> On Sun, Jan 10, 2010 at 05:58, Naftoli Gugenheim
>> >>> wrote:
>> >>>> Did you search for the discussion? This was all discussed very openly
>> >>>> at length, quite a while ago. After you read the discussion if you have
>> >>>> questions ask them, although it's probably too late.
>> >>>
>> >>> No, it is not too late, 2.8 even is not beta yet.
>> >>>
>> >>> I searched (now), I have found several discussions where 2.7 package
>> >>> importing mechanism compared to 2.8 mechanism.
>> >>>
>> >>> I haven't found a discussion of what I'd like to have: "import a.b.C"
>> >>> statement imports from (maybe) several packages.
>> >>>
>> >>> S.
>> >>>
>> >>>
>> >>>> -------------------------------------
>> >>>> Stepan Koltsov wrote:
>> >>>>
>> >>>> On Sun, Jan 10, 2010 at 05:17, jherber wrote:
>> >>>>>
>> >>>>> what if you thought you were importing
>> >>>>> com.myco.wrappers.java.io.File (but
>> >>>>> you had not finished the implementation)?  in your scenario
>> >>>>> java.io.File
>> >>>>> would be pulled into scope with no warning or error.  A subtle bug
>> >>>>> is then
>> >>>>> introduced.
>> >>>>
>> >>>> I said, if both classes match "import java.io.File", no class should
>> >>>> be imported. Attempt to use File identifier should be an error.
>> >>>>
>> >>>> Anyway, having several classes with same name in single project is a
>> >>>> bad idea. AFAIU, intent of new package importing mechanism is to
>> >>>> protect against duplicate package names, not against duplicate class
>> >>>> names.
>> >>>>
>> >>>> I don't understand, why new verbose package declaration syntax (that
>> >>>> also breaks existing code) does not annoy people. Why doesn't
>> >>>> everyone
>> >>>> complain? Maybe I miss something...
>> >>>>
>> >>>> S.
>> >>>>
>> >>>>
>> >>>>> What might be nice is for Martin to save our poor fingers and eyes
>> >>>>> from
>> >>>>> having "_root_" noise up our code, by allowing "_" to be a
>> >>>>> placeholder for
>> >>>>> "_root_" at the beginning of import path.
>> >>>>>
>> >>>>> "import _.java.io.File" would imply "import _root_.java.io.File"
>> >>>>>
>> >>>>> and
>> >>>>>
>> >>>>> "import _.java.io._" would imply "import _root_.java.io._"
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>> Why can't "import java.io.File" import both _root_.java.io.File and
>> >>>>>> com.mycompany.wrappers.java.io.File ? (successfully if at least one
>> >>>>>> exists)
>> >>>>>
>> >>>>> I meant "successfully if exacly one of java.io.File and
>> >>>>> com.mycompany.wrappers.java.io.File avaiable".
>> >>>>>
>> >>>>> S.
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> --
>> >>>>> View this message in context:
>> >>>>> http://old.nabble.com/package-declaration-syntax-tp27081262p27095040.html
>> >>>>> Sent from the Scala - User mailing list archive at Nabble.com.
>> >>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> >
>> >
>> >
>> > --
>> > Johannes
>> >
>> > -----------------------------------------------
>> > Johannes Rudolph
>> > http://virtual-void.net
>> >
>
>
>
> --
> Daniel C. Sobral
>
> I travel to the future all the time.
>

Let me restate this. I want all my imports to import only what I _think_ it will be importing. Ah, forget it. I want precisely NOT what you are suggesting, so we are at odds here....

On Sun, Jan 10, 2010 at 3:01 PM, Stepan Koltsov <stepan.koltsov@gmail.com> wrote:

On Sun, Jan 10, 2010 at 19:42, Daniel Sobral <dcsobral@gmail.com> wrote:
> And how would you go about avoiding importing more than you want?

import _root_.a.b.C imports only _root_.a.b.C

import mycompany.a.b.C imports only _root_.com.mycompany.a.b.C

But precise import is rarely needed, because duplicate class names are
rare (unlike duplicate package names).

S.


> On Sun, Jan 10, 2010 at 2:21 PM, Stepan Koltsov <stepan.koltsov@gmail.com>
> wrote:
>>
>> On Sun, Jan 10, 2010 at 13:18, Johannes Rudolph
>> <johannes.rudolph@googlemail.com> wrote:
>> > http://old.nabble.com/Revisiting-absolute-relative-paths-to24492690.html
>> >
>> > http://old.nabble.com/Nested-package-scopes-vs.-Imports-%28Was%3A-Revisiting--absolute-relative-paths%29-tp24517644p24518578.html
>>
>> Neither link discusses what I want: "import a.b.C" imports C from one
>> of _root_.a.b, com.a.b, com.mycompany.a.b, com.mycompany.program.a.b
>> if only one exists.
>>
>> S.
>>
>>
>> > On Sun, Jan 10, 2010 at 4:37 AM, Naftoli Gugenheim
>> > <naftoligug@gmail.com> wrote:
>> >> It was a long one, and included Martin Odersky, so that should narrow
>> >> it down.
>> >>
>> >> -------------------------------------
>> >> Stepan Koltsov<stepan.koltsov@gmail.com> wrote:
>> >>
>> >> On Sun, Jan 10, 2010 at 06:31, Naftoli Gugenheim <naftoligug@gmail.com>
>> >> wrote:
>> >>> Maybe someone can link to the right thread?
>> >>
>> >> You meant there was a thread? And similar proposal was rejected?
>> >>
>> >> S.
>> >>
>> >>
>> >>> -------------------------------------
>> >>> Stepan Koltsov<stepan.koltsov@gmail.com> wrote:
>> >>>
>> >>> On Sun, Jan 10, 2010 at 05:58, Naftoli Gugenheim
>> >>> <naftoligug@gmail.com> wrote:
>> >>>> Did you search for the discussion? This was all discussed very openly
>> >>>> at length, quite a while ago. After you read the discussion if you have
>> >>>> questions ask them, although it's probably too late.
>> >>>
>> >>> No, it is not too late, 2.8 even is not beta yet.
>> >>>
>> >>> I searched (now), I have found several discussions where 2.7 package
>> >>> importing mechanism compared to 2.8 mechanism.
>> >>>
>> >>> I haven't found a discussion of what I'd like to have: "import a.b.C"
>> >>> statement imports from (maybe) several packages.
>> >>>
>> >>> S.
>> >>>
>> >>>
>> >>>> -------------------------------------
>> >>>> Stepan Koltsov<stepan.koltsov@gmail.com> wrote:
>> >>>>
>> >>>> On Sun, Jan 10, 2010 at 05:17, jherber <jimherber@gmail.com> wrote:
>> >>>>>
>> >>>>> what if you thought you were importing
>> >>>>> com.myco.wrappers.java.io.File (but
>> >>>>> you had not finished the implementation)?  in your scenario
>> >>>>> java.io.File
>> >>>>> would be pulled into scope with no warning or error.  A subtle bug
>> >>>>> is then
>> >>>>> introduced.
>> >>>>
>> >>>> I said, if both classes match "import java.io.File", no class should
>> >>>> be imported. Attempt to use File identifier should be an error.
>> >>>>
>> >>>> Anyway, having several classes with same name in single project is a
>> >>>> bad idea. AFAIU, intent of new package importing mechanism is to
>> >>>> protect against duplicate package names, not against duplicate class
>> >>>> names.
>> >>>>
>> >>>> I don't understand, why new verbose package declaration syntax (that
>> >>>> also breaks existing code) does not annoy people. Why doesn't
>> >>>> everyone
>> >>>> complain? Maybe I miss something...
>> >>>>
>> >>>> S.
>> >>>>
>> >>>>
>> >>>>> What might be nice is for Martin to save our poor fingers and eyes
>> >>>>> from
>> >>>>> having "_root_" noise up our code, by allowing "_" to be a
>> >>>>> placeholder for
>> >>>>> "_root_" at the beginning of import path.
>> >>>>>
>> >>>>> "import _.java.io.File" would imply "import _root_.java.io.File"
>> >>>>>
>> >>>>> and
>> >>>>>
>> >>>>> "import _.java.io._" would imply "import _root_.java.io._"
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>> Why can't "import java.io.File" import both _root_.java.io.File and
>> >>>>>> com.mycompany.wrappers.java.io.File ? (successfully if at least one
>> >>>>>> exists)
>> >>>>>
>> >>>>> I meant "successfully if exacly one of java.io.File and
>> >>>>> com.mycompany.wrappers.java.io.File avaiable".
>> >>>>>
>> >>>>> S.
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> --
>> >>>>> View this message in context:
>> >>>>> http://old.nabble.com/package-declaration-syntax-tp27081262p27095040.html
>> >>>>> Sent from the Scala - User mailing list archive at Nabble.com.
>> >>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> >
>> >
>> >
>> > --
>> > Johannes
>> >
>> > -----------------------------------------------
>> > Johannes Rudolph
>> > http://virtual-void.net
>> >
>
>
>
> --
> Daniel C. Sobral
>
> I travel to the future all the time.
>

--
Daniel C. Sobral

I travel to the future all the time.

On Sun, Jan 10, 2010 at 20:20, Daniel Sobral wrote:
> Let me restate this. I want all my imports to import only what I _think_ it
> will be importing.

You will import exactly what you want. If you have only only one C
class, it will be imported by statement "import a.b.C". Problem with
2.7 is that "import a.c.C" may not import C at all, this problem is
solved.

S.

> On Sun, Jan 10, 2010 at 3:01 PM, Stepan Koltsov
> wrote:
>>
>> On Sun, Jan 10, 2010 at 19:42, Daniel Sobral wrote:
>> > And how would you go about avoiding importing more than you want?
>>
>> import _root_.a.b.C imports only _root_.a.b.C
>>
>> import mycompany.a.b.C imports only _root_.com.mycompany.a.b.C
>>
>> But precise import is rarely needed, because duplicate class names are
>> rare (unlike duplicate package names).
>>
>> S.
>>
>>
>> > On Sun, Jan 10, 2010 at 2:21 PM, Stepan Koltsov
>> >
>> > wrote:
>> >>
>> >> On Sun, Jan 10, 2010 at 13:18, Johannes Rudolph
>> >> wrote:
>> >> >
>> >> > http://old.nabble.com/Revisiting-absolute-relative-paths-to24492690.html
>> >> >
>> >> >
>> >> > http://old.nabble.com/Nested-package-scopes-vs.-Imports-%28Was%3A-Revisi...
>> >>
>> >> Neither link discusses what I want: "import a.b.C" imports C from one
>> >> of _root_.a.b, com.a.b, com.mycompany.a.b, com.mycompany.program.a.b
>> >> if only one exists.
>> >>
>> >> S.
>> >>
>> >>
>> >> > On Sun, Jan 10, 2010 at 4:37 AM, Naftoli Gugenheim
>> >> > wrote:
>> >> >> It was a long one, and included Martin Odersky, so that should
>> >> >> narrow
>> >> >> it down.
>> >> >>
>> >> >> -------------------------------------
>> >> >> Stepan Koltsov wrote:
>> >> >>
>> >> >> On Sun, Jan 10, 2010 at 06:31, Naftoli Gugenheim
>> >> >>
>> >> >> wrote:
>> >> >>> Maybe someone can link to the right thread?
>> >> >>
>> >> >> You meant there was a thread? And similar proposal was rejected?
>> >> >>
>> >> >> S.
>> >> >>
>> >> >>
>> >> >>> -------------------------------------
>> >> >>> Stepan Koltsov wrote:
>> >> >>>
>> >> >>> On Sun, Jan 10, 2010 at 05:58, Naftoli Gugenheim
>> >> >>> wrote:
>> >> >>>> Did you search for the discussion? This was all discussed very
>> >> >>>> openly
>> >> >>>> at length, quite a while ago. After you read the discussion if you
>> >> >>>> have
>> >> >>>> questions ask them, although it's probably too late.
>> >> >>>
>> >> >>> No, it is not too late, 2.8 even is not beta yet.
>> >> >>>
>> >> >>> I searched (now), I have found several discussions where 2.7
>> >> >>> package
>> >> >>> importing mechanism compared to 2.8 mechanism.
>> >> >>>
>> >> >>> I haven't found a discussion of what I'd like to have: "import
>> >> >>> a.b.C"
>> >> >>> statement imports from (maybe) several packages.
>> >> >>>
>> >> >>> S.
>> >> >>>
>> >> >>>
>> >> >>>> -------------------------------------
>> >> >>>> Stepan Koltsov wrote:
>> >> >>>>
>> >> >>>> On Sun, Jan 10, 2010 at 05:17, jherber
>> >> >>>> wrote:
>> >> >>>>>
>> >> >>>>> what if you thought you were importing
>> >> >>>>> com.myco.wrappers.java.io.File (but
>> >> >>>>> you had not finished the implementation)?  in your scenario
>> >> >>>>> java.io.File
>> >> >>>>> would be pulled into scope with no warning or error.  A subtle
>> >> >>>>> bug
>> >> >>>>> is then
>> >> >>>>> introduced.
>> >> >>>>
>> >> >>>> I said, if both classes match "import java.io.File", no class
>> >> >>>> should
>> >> >>>> be imported. Attempt to use File identifier should be an error.
>> >> >>>>
>> >> >>>> Anyway, having several classes with same name in single project is
>> >> >>>> a
>> >> >>>> bad idea. AFAIU, intent of new package importing mechanism is to
>> >> >>>> protect against duplicate package names, not against duplicate
>> >> >>>> class
>> >> >>>> names.
>> >> >>>>
>> >> >>>> I don't understand, why new verbose package declaration syntax
>> >> >>>> (that
>> >> >>>> also breaks existing code) does not annoy people. Why doesn't
>> >> >>>> everyone
>> >> >>>> complain? Maybe I miss something...
>> >> >>>>
>> >> >>>> S.
>> >> >>>>
>> >> >>>>
>> >> >>>>> What might be nice is for Martin to save our poor fingers and
>> >> >>>>> eyes
>> >> >>>>> from
>> >> >>>>> having "_root_" noise up our code, by allowing "_" to be a
>> >> >>>>> placeholder for
>> >> >>>>> "_root_" at the beginning of import path.
>> >> >>>>>
>> >> >>>>> "import _.java.io.File" would imply "import _root_.java.io.File"
>> >> >>>>>
>> >> >>>>> and
>> >> >>>>>
>> >> >>>>> "import _.java.io._" would imply "import _root_.java.io._"
>> >> >>>>>
>> >> >>>>>
>> >> >>>>>
>> >> >>>>>
>> >> >>>>>> Why can't "import java.io.File" import both _root_.java.io.File
>> >> >>>>>> and
>> >> >>>>>> com.mycompany.wrappers.java.io.File ? (successfully if at least
>> >> >>>>>> one
>> >> >>>>>> exists)
>> >> >>>>>
>> >> >>>>> I meant "successfully if exacly one of java.io.File and
>> >> >>>>> com.mycompany.wrappers.java.io.File avaiable".
>> >> >>>>>
>> >> >>>>> S.
>> >> >>>>>
>> >> >>>>>
>> >> >>>>>
>> >> >>>>> --
>> >> >>>>> View this message in context:
>> >> >>>>>
>> >> >>>>> http://old.nabble.com/package-declaration-syntax-tp27081262p27095040.html
>> >> >>>>> Sent from the Scala - User mailing list archive at Nabble.com.
>> >> >>>>>
>> >> >>>>>
>> >> >>>>
>> >> >>>
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Johannes
>> >> >
>> >> > -----------------------------------------------
>> >> > Johannes Rudolph
>> >> > http://virtual-void.net
>> >> >
>> >
>> >
>> >
>> > --
>> > Daniel C. Sobral
>> >
>> > I travel to the future all the time.
>> >
>
>
>
> --
> Daniel C. Sobral
>
> I travel to the future all the time.
>

Well, there's that little "if" problem. And, then, there's import "a.b._".

On Sun, Jan 10, 2010 at 3:30 PM, Stepan Koltsov <stepan.koltsov@gmail.com> wrote:

On Sun, Jan 10, 2010 at 20:20, Daniel Sobral <dcsobral@gmail.com> wrote:
> Let me restate this. I want all my imports to import only what I _think_ it
> will be importing.

You will import exactly what you want. If you have only only one C
class, it will be imported by statement "import a.b.C". Problem with
2.7 is that "import a.c.C" may not import C at all, this problem is
solved.

S.


> On Sun, Jan 10, 2010 at 3:01 PM, Stepan Koltsov <stepan.koltsov@gmail.com>
> wrote:
>>
>> On Sun, Jan 10, 2010 at 19:42, Daniel Sobral <dcsobral@gmail.com> wrote:
>> > And how would you go about avoiding importing more than you want?
>>
>> import _root_.a.b.C imports only _root_.a.b.C
>>
>> import mycompany.a.b.C imports only _root_.com.mycompany.a.b.C
>>
>> But precise import is rarely needed, because duplicate class names are
>> rare (unlike duplicate package names).
>>
>> S.
>>
>>
>> > On Sun, Jan 10, 2010 at 2:21 PM, Stepan Koltsov
>> > <stepan.koltsov@gmail.com>
>> > wrote:
>> >>
>> >> On Sun, Jan 10, 2010 at 13:18, Johannes Rudolph
>> >> <johannes.rudolph@googlemail.com> wrote:
>> >> >
>> >> > http://old.nabble.com/Revisiting-absolute-relative-paths-to24492690.html
>> >> >
>> >> >
>> >> > http://old.nabble.com/Nested-package-scopes-vs.-Imports-%28Was%3A-Revisiting--absolute-relative-paths%29-tp24517644p24518578.html
>> >>
>> >> Neither link discusses what I want: "import a.b.C" imports C from one
>> >> of _root_.a.b, com.a.b, com.mycompany.a.b, com.mycompany.program.a.b
>> >> if only one exists.
>> >>
>> >> S.
>> >>
>> >>
>> >> > On Sun, Jan 10, 2010 at 4:37 AM, Naftoli Gugenheim
>> >> > <naftoligug@gmail.com> wrote:
>> >> >> It was a long one, and included Martin Odersky, so that should
>> >> >> narrow
>> >> >> it down.
>> >> >>
>> >> >> -------------------------------------
>> >> >> Stepan Koltsov<stepan.koltsov@gmail.com> wrote:
>> >> >>
>> >> >> On Sun, Jan 10, 2010 at 06:31, Naftoli Gugenheim
>> >> >> <naftoligug@gmail.com>
>> >> >> wrote:
>> >> >>> Maybe someone can link to the right thread?
>> >> >>
>> >> >> You meant there was a thread? And similar proposal was rejected?
>> >> >>
>> >> >> S.
>> >> >>
>> >> >>
>> >> >>> -------------------------------------
>> >> >>> Stepan Koltsov<stepan.koltsov@gmail.com> wrote:
>> >> >>>
>> >> >>> On Sun, Jan 10, 2010 at 05:58, Naftoli Gugenheim
>> >> >>> <naftoligug@gmail.com> wrote:
>> >> >>>> Did you search for the discussion? This was all discussed very
>> >> >>>> openly
>> >> >>>> at length, quite a while ago. After you read the discussion if you
>> >> >>>> have
>> >> >>>> questions ask them, although it's probably too late.
>> >> >>>
>> >> >>> No, it is not too late, 2.8 even is not beta yet.
>> >> >>>
>> >> >>> I searched (now), I have found several discussions where 2.7
>> >> >>> package
>> >> >>> importing mechanism compared to 2.8 mechanism.
>> >> >>>
>> >> >>> I haven't found a discussion of what I'd like to have: "import
>> >> >>> a.b.C"
>> >> >>> statement imports from (maybe) several packages.
>> >> >>>
>> >> >>> S.
>> >> >>>
>> >> >>>
>> >> >>>> -------------------------------------
>> >> >>>> Stepan Koltsov<stepan.koltsov@gmail.com> wrote:
>> >> >>>>
>> >> >>>> On Sun, Jan 10, 2010 at 05:17, jherber <jimherber@gmail.com>
>> >> >>>> wrote:
>> >> >>>>>
>> >> >>>>> what if you thought you were importing
>> >> >>>>> com.myco.wrappers.java.io.File (but
>> >> >>>>> you had not finished the implementation)?  in your scenario
>> >> >>>>> java.io.File
>> >> >>>>> would be pulled into scope with no warning or error.  A subtle
>> >> >>>>> bug
>> >> >>>>> is then
>> >> >>>>> introduced.
>> >> >>>>
>> >> >>>> I said, if both classes match "import java.io.File", no class
>> >> >>>> should
>> >> >>>> be imported. Attempt to use File identifier should be an error.
>> >> >>>>
>> >> >>>> Anyway, having several classes with same name in single project is
>> >> >>>> a
>> >> >>>> bad idea. AFAIU, intent of new package importing mechanism is to
>> >> >>>> protect against duplicate package names, not against duplicate
>> >> >>>> class
>> >> >>>> names.
>> >> >>>>
>> >> >>>> I don't understand, why new verbose package declaration syntax
>> >> >>>> (that
>> >> >>>> also breaks existing code) does not annoy people. Why doesn't
>> >> >>>> everyone
>> >> >>>> complain? Maybe I miss something...
>> >> >>>>
>> >> >>>> S.
>> >> >>>>
>> >> >>>>
>> >> >>>>> What might be nice is for Martin to save our poor fingers and
>> >> >>>>> eyes
>> >> >>>>> from
>> >> >>>>> having "_root_" noise up our code, by allowing "_" to be a
>> >> >>>>> placeholder for
>> >> >>>>> "_root_" at the beginning of import path.
>> >> >>>>>
>> >> >>>>> "import _.java.io.File" would imply "import _root_.java.io.File"
>> >> >>>>>
>> >> >>>>> and
>> >> >>>>>
>> >> >>>>> "import _.java.io._" would imply "import _root_.java.io._"
>> >> >>>>>
>> >> >>>>>
>> >> >>>>>
>> >> >>>>>
>> >> >>>>>> Why can't "import java.io.File" import both _root_.java.io.File
>> >> >>>>>> and
>> >> >>>>>> com.mycompany.wrappers.java.io.File ? (successfully if at least
>> >> >>>>>> one
>> >> >>>>>> exists)
>> >> >>>>>
>> >> >>>>> I meant "successfully if exacly one of java.io.File and
>> >> >>>>> com.mycompany.wrappers.java.io.File avaiable".
>> >> >>>>>
>> >> >>>>> S.
>> >> >>>>>
>> >> >>>>>
>> >> >>>>>
>> >> >>>>> --
>> >> >>>>> View this message in context:
>> >> >>>>>
>> >> >>>>> http://old.nabble.com/package-declaration-syntax-tp27081262p27095040.html
>> >> >>>>> Sent from the Scala - User mailing list archive at Nabble.com.
>> >> >>>>>
>> >> >>>>>
>> >> >>>>
>> >> >>>
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Johannes
>> >> >
>> >> > -----------------------------------------------
>> >> > Johannes Rudolph
>> >> > http://virtual-void.net
>> >> >
>> >
>> >
>> >
>> > --
>> > Daniel C. Sobral
>> >
>> > I travel to the future all the time.
>> >
>
>
>
> --
> Daniel C. Sobral
>
> I travel to the future all the time.
>

--
Daniel C. Sobral

I travel to the future all the time.

On Sun, Jan 10, 2010 at 20:42, Daniel Sobral wrote:
> Well, there's that little "if" problem.

As I said, duplicate class names are rare, it is not a big problem.

Much bigger problem is a verbose header in each files, that is
necessary to use relative imports with current 2.8 syntax.

> And, then, there's import "a.b._".

It doesn't matter, whether you type "import a.b._" and use class C, or
"import a.b.C" and use class C.

S.

> On Sun, Jan 10, 2010 at 3:30 PM, Stepan Koltsov
> wrote:
>>
>> On Sun, Jan 10, 2010 at 20:20, Daniel Sobral wrote:
>> > Let me restate this. I want all my imports to import only what I _think_
>> > it
>> > will be importing.
>>
>> You will import exactly what you want. If you have only only one C
>> class, it will be imported by statement "import a.b.C". Problem with
>> 2.7 is that "import a.c.C" may not import C at all, this problem is
>> solved.
>>
>> S.
>>
>>
>> > On Sun, Jan 10, 2010 at 3:01 PM, Stepan Koltsov
>> >
>> > wrote:
>> >>
>> >> On Sun, Jan 10, 2010 at 19:42, Daniel Sobral
>> >> wrote:
>> >> > And how would you go about avoiding importing more than you want?
>> >>
>> >> import _root_.a.b.C imports only _root_.a.b.C
>> >>
>> >> import mycompany.a.b.C imports only _root_.com.mycompany.a.b.C
>> >>
>> >> But precise import is rarely needed, because duplicate class names are
>> >> rare (unlike duplicate package names).
>> >>
>> >> S.
>> >>
>> >>
>> >> > On Sun, Jan 10, 2010 at 2:21 PM, Stepan Koltsov
>> >> >
>> >> > wrote:
>> >> >>
>> >> >> On Sun, Jan 10, 2010 at 13:18, Johannes Rudolph
>> >> >> wrote:
>> >> >> >
>> >> >> >
>> >> >> > http://old.nabble.com/Revisiting-absolute-relative-paths-to24492690.html
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > http://old.nabble.com/Nested-package-scopes-vs.-Imports-%28Was%3A-Revisi...
>> >> >>
>> >> >> Neither link discusses what I want: "import a.b.C" imports C from
>> >> >> one
>> >> >> of _root_.a.b, com.a.b, com.mycompany.a.b, com.mycompany.program.a.b
>> >> >> if only one exists.
>> >> >>
>> >> >> S.
>> >> >>
>> >> >>
>> >> >> > On Sun, Jan 10, 2010 at 4:37 AM, Naftoli Gugenheim
>> >> >> > wrote:
>> >> >> >> It was a long one, and included Martin Odersky, so that should
>> >> >> >> narrow
>> >> >> >> it down.
>> >> >> >>
>> >> >> >> -------------------------------------
>> >> >> >> Stepan Koltsov wrote:
>> >> >> >>
>> >> >> >> On Sun, Jan 10, 2010 at 06:31, Naftoli Gugenheim
>> >> >> >>
>> >> >> >> wrote:
>> >> >> >>> Maybe someone can link to the right thread?
>> >> >> >>
>> >> >> >> You meant there was a thread? And similar proposal was rejected?
>> >> >> >>
>> >> >> >> S.
>> >> >> >>
>> >> >> >>
>> >> >> >>> -------------------------------------
>> >> >> >>> Stepan Koltsov wrote:
>> >> >> >>>
>> >> >> >>> On Sun, Jan 10, 2010 at 05:58, Naftoli Gugenheim
>> >> >> >>> wrote:
>> >> >> >>>> Did you search for the discussion? This was all discussed very
>> >> >> >>>> openly
>> >> >> >>>> at length, quite a while ago. After you read the discussion if
>> >> >> >>>> you
>> >> >> >>>> have
>> >> >> >>>> questions ask them, although it's probably too late.
>> >> >> >>>
>> >> >> >>> No, it is not too late, 2.8 even is not beta yet.
>> >> >> >>>
>> >> >> >>> I searched (now), I have found several discussions where 2.7
>> >> >> >>> package
>> >> >> >>> importing mechanism compared to 2.8 mechanism.
>> >> >> >>>
>> >> >> >>> I haven't found a discussion of what I'd like to have: "import
>> >> >> >>> a.b.C"
>> >> >> >>> statement imports from (maybe) several packages.
>> >> >> >>>
>> >> >> >>> S.
>> >> >> >>>
>> >> >> >>>
>> >> >> >>>> -------------------------------------
>> >> >> >>>> Stepan Koltsov wrote:
>> >> >> >>>>
>> >> >> >>>> On Sun, Jan 10, 2010 at 05:17, jherber
>> >> >> >>>> wrote:
>> >> >> >>>>>
>> >> >> >>>>> what if you thought you were importing
>> >> >> >>>>> com.myco.wrappers.java.io.File (but
>> >> >> >>>>> you had not finished the implementation)?  in your scenario
>> >> >> >>>>> java.io.File
>> >> >> >>>>> would be pulled into scope with no warning or error.  A subtle
>> >> >> >>>>> bug
>> >> >> >>>>> is then
>> >> >> >>>>> introduced.
>> >> >> >>>>
>> >> >> >>>> I said, if both classes match "import java.io.File", no class
>> >> >> >>>> should
>> >> >> >>>> be imported. Attempt to use File identifier should be an error.
>> >> >> >>>>
>> >> >> >>>> Anyway, having several classes with same name in single project
>> >> >> >>>> is
>> >> >> >>>> a
>> >> >> >>>> bad idea. AFAIU, intent of new package importing mechanism is
>> >> >> >>>> to
>> >> >> >>>> protect against duplicate package names, not against duplicate
>> >> >> >>>> class
>> >> >> >>>> names.
>> >> >> >>>>
>> >> >> >>>> I don't understand, why new verbose package declaration syntax
>> >> >> >>>> (that
>> >> >> >>>> also breaks existing code) does not annoy people. Why doesn't
>> >> >> >>>> everyone
>> >> >> >>>> complain? Maybe I miss something...
>> >> >> >>>>
>> >> >> >>>> S.
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>>> What might be nice is for Martin to save our poor fingers and
>> >> >> >>>>> eyes
>> >> >> >>>>> from
>> >> >> >>>>> having "_root_" noise up our code, by allowing "_" to be a
>> >> >> >>>>> placeholder for
>> >> >> >>>>> "_root_" at the beginning of import path.
>> >> >> >>>>>
>> >> >> >>>>> "import _.java.io.File" would imply "import
>> >> >> >>>>> _root_.java.io.File"
>> >> >> >>>>>
>> >> >> >>>>> and
>> >> >> >>>>>
>> >> >> >>>>> "import _.java.io._" would imply "import _root_.java.io._"
>> >> >> >>>>>
>> >> >> >>>>>
>> >> >> >>>>>
>> >> >> >>>>>
>> >> >> >>>>>> Why can't "import java.io.File" import both
>> >> >> >>>>>> _root_.java.io.File
>> >> >> >>>>>> and
>> >> >> >>>>>> com.mycompany.wrappers.java.io.File ? (successfully if at
>> >> >> >>>>>> least
>> >> >> >>>>>> one
>> >> >> >>>>>> exists)
>> >> >> >>>>>
>> >> >> >>>>> I meant "successfully if exacly one of java.io.File and
>> >> >> >>>>> com.mycompany.wrappers.java.io.File avaiable".
>> >> >> >>>>>
>> >> >> >>>>> S.
>> >> >> >>>>>
>> >> >> >>>>>
>> >> >> >>>>>
>> >> >> >>>>> --
>> >> >> >>>>> View this message in context:
>> >> >> >>>>>
>> >> >> >>>>>
>> >> >> >>>>> http://old.nabble.com/package-declaration-syntax-tp27081262p27095040.html
>> >> >> >>>>> Sent from the Scala - User mailing list archive at Nabble.com.
>> >> >> >>>>>
>> >> >> >>>>>
>> >> >> >>>>
>> >> >> >>>
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > Johannes
>> >> >> >
>> >> >> > -----------------------------------------------
>> >> >> > Johannes Rudolph
>> >> >> > http://virtual-void.net
>> >> >> >
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Daniel C. Sobral
>> >> >
>> >> > I travel to the future all the time.
>> >> >
>> >
>> >
>> >
>> > --
>> > Daniel C. Sobral
>> >
>> > I travel to the future all the time.
>> >
>
>
>
> --
> Daniel C. Sobral
>
> I travel to the future all the time.
>

Take it to stackoverflow... The votes will reveal all!
To quote none other than Martin Odersky: "Not at all. I agree completely. Stackoverflow is the best place to ask questions."

2010/1/10 Daniel Sobral <dcsobral@gmail.com>

Well, there's that little "if" problem. And, then, there's import "a.b._".

On Sun, Jan 10, 2010 at 3:30 PM, Stepan Koltsov <stepan.koltsov@gmail.com> wrote:

On Sun, Jan 10, 2010 at 20:20, Daniel Sobral <dcsobral@gmail.com> wrote:
> Let me restate this. I want all my imports to import only what I _think_ it
> will be importing.

You will import exactly what you want. If you have only only one C
class, it will be imported by statement "import a.b.C". Problem with
2.7 is that "import a.c.C" may not import C at all, this problem is
solved.

S.


> On Sun, Jan 10, 2010 at 3:01 PM, Stepan Koltsov <stepan.koltsov@gmail.com>
> wrote:
>>
>> On Sun, Jan 10, 2010 at 19:42, Daniel Sobral <dcsobral@gmail.com> wrote:
>> > And how would you go about avoiding importing more than you want?
>>
>> import _root_.a.b.C imports only _root_.a.b.C
>>
>> import mycompany.a.b.C imports only _root_.com.mycompany.a.b.C
>>
>> But precise import is rarely needed, because duplicate class names are
>> rare (unlike duplicate package names).
>>
>> S.
>>
>>
>> > On Sun, Jan 10, 2010 at 2:21 PM, Stepan Koltsov
>> > <stepan.koltsov@gmail.com>
>> > wrote:
>> >>
>> >> On Sun, Jan 10, 2010 at 13:18, Johannes Rudolph
>> >> <johannes.rudolph@googlemail.com> wrote:
>> >> >
>> >> > http://old.nabble.com/Revisiting-absolute-relative-paths-to24492690.html
>> >> >
>> >> >
>> >> > http://old.nabble.com/Nested-package-scopes-vs.-Imports-%28Was%3A-Revisiting--absolute-relative-paths%29-tp24517644p24518578.html
>> >>
>> >> Neither link discusses what I want: "import a.b.C" imports C from one
>> >> of _root_.a.b, com.a.b, com.mycompany.a.b, com.mycompany.program.a.b
>> >> if only one exists.
>> >>
>> >> S.
>> >>
>> >>
>> >> > On Sun, Jan 10, 2010 at 4:37 AM, Naftoli Gugenheim
>> >> > <naftoligug@gmail.com> wrote:
>> >> >> It was a long one, and included Martin Odersky, so that should
>> >> >> narrow
>> >> >> it down.
>> >> >>
>> >> >> -------------------------------------
>> >> >> Stepan Koltsov<stepan.koltsov@gmail.com> wrote:
>> >> >>
>> >> >> On Sun, Jan 10, 2010 at 06:31, Naftoli Gugenheim
>> >> >> <naftoligug@gmail.com>
>> >> >> wrote:
>> >> >>> Maybe someone can link to the right thread?
>> >> >>
>> >> >> You meant there was a thread? And similar proposal was rejected?
>> >> >>
>> >> >> S.
>> >> >>
>> >> >>
>> >> >>> -------------------------------------
>> >> >>> Stepan Koltsov<stepan.koltsov@gmail.com> wrote:
>> >> >>>
>> >> >>> On Sun, Jan 10, 2010 at 05:58, Naftoli Gugenheim
>> >> >>> <naftoligug@gmail.com> wrote:
>> >> >>>> Did you search for the discussion? This was all discussed very
>> >> >>>> openly
>> >> >>>> at length, quite a while ago. After you read the discussion if you
>> >> >>>> have
>> >> >>>> questions ask them, although it's probably too late.
>> >> >>>
>> >> >>> No, it is not too late, 2.8 even is not beta yet.
>> >> >>>
>> >> >>> I searched (now), I have found several discussions where 2.7
>> >> >>> package
>> >> >>> importing mechanism compared to 2.8 mechanism.
>> >> >>>
>> >> >>> I haven't found a discussion of what I'd like to have: "import
>> >> >>> a.b.C"
>> >> >>> statement imports from (maybe) several packages.
>> >> >>>
>> >> >>> S.
>> >> >>>
>> >> >>>
>> >> >>>> -------------------------------------
>> >> >>>> Stepan Koltsov<stepan.koltsov@gmail.com> wrote:
>> >> >>>>
>> >> >>>> On Sun, Jan 10, 2010 at 05:17, jherber <jimherber@gmail.com>
>> >> >>>> wrote:
>> >> >>>>>
>> >> >>>>> what if you thought you were importing
>> >> >>>>> com.myco.wrappers.java.io.File (but
>> >> >>>>> you had not finished the implementation)?  in your scenario
>> >> >>>>> java.io.File
>> >> >>>>> would be pulled into scope with no warning or error.  A subtle
>> >> >>>>> bug
>> >> >>>>> is then
>> >> >>>>> introduced.
>> >> >>>>
>> >> >>>> I said, if both classes match "import java.io.File", no class
>> >> >>>> should
>> >> >>>> be imported. Attempt to use File identifier should be an error.
>> >> >>>>
>> >> >>>> Anyway, having several classes with same name in single project is
>> >> >>>> a
>> >> >>>> bad idea. AFAIU, intent of new package importing mechanism is to
>> >> >>>> protect against duplicate package names, not against duplicate
>> >> >>>> class
>> >> >>>> names.
>> >> >>>>
>> >> >>>> I don't understand, why new verbose package declaration syntax
>> >> >>>> (that
>> >> >>>> also breaks existing code) does not annoy people. Why doesn't
>> >> >>>> everyone
>> >> >>>> complain? Maybe I miss something...
>> >> >>>>
>> >> >>>> S.
>> >> >>>>
>> >> >>>>
>> >> >>>>> What might be nice is for Martin to save our poor fingers and
>> >> >>>>> eyes
>> >> >>>>> from
>> >> >>>>> having "_root_" noise up our code, by allowing "_" to be a
>> >> >>>>> placeholder for
>> >> >>>>> "_root_" at the beginning of import path.
>> >> >>>>>
>> >> >>>>> "import _.java.io.File" would imply "import _root_.java.io.File"
>> >> >>>>>
>> >> >>>>> and
>> >> >>>>>
>> >> >>>>> "import _.java.io._" would imply "import _root_.java.io._"
>> >> >>>>>
>> >> >>>>>
>> >> >>>>>
>> >> >>>>>
>> >> >>>>>> Why can't "import java.io.File" import both _root_.java.io.File
>> >> >>>>>> and
>> >> >>>>>> com.mycompany.wrappers.java.io.File ? (successfully if at least
>> >> >>>>>> one
>> >> >>>>>> exists)
>> >> >>>>>
>> >> >>>>> I meant "successfully if exacly one of java.io.File and
>> >> >>>>> com.mycompany.wrappers.java.io.File avaiable".
>> >> >>>>>
>> >> >>>>> S.
>> >> >>>>>
>> >> >>>>>
>> >> >>>>>
>> >> >>>>> --
>> >> >>>>> View this message in context:
>> >> >>>>>
>> >> >>>>> http://old.nabble.com/package-declaration-syntax-tp27081262p27095040.html
>> >> >>>>> Sent from the Scala - User mailing list archive at Nabble.com.
>> >> >>>>>
>> >> >>>>>
>> >> >>>>
>> >> >>>
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Johannes
>> >> >
>> >> > -----------------------------------------------
>> >> > Johannes Rudolph
>> >> > http://virtual-void.net
>> >> >
>> >
>> >
>> >
>> > --
>> > Daniel C. Sobral
>> >
>> > I travel to the future all the time.
>> >
>
>
>
> --
> Daniel C. Sobral
>
> I travel to the future all the time.
>

--
Daniel C. Sobral

I travel to the future all the time.

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

(Let's try this again, I forgot to reply to all...)
It's maybe a bit more verbose, but certainly not in a bad way.  These are only lines at the top of the file, you can simply scroll past them!
In addition, this syntax carries extra semantic meaning.  Consider the following:
  package com.mycompany.funkyproject  package foo  package bar
  class ...
It's now made *very* clear that "com.mycompany.funkyproject" is an atomic construct being used as a unique namespace, and that that we're not granting any special privileges to the `com` package.
Remember that this isn't only about where imports will search, it's also about bringing package objects and contained implicits into scope.


2010/1/10 Stepan Koltsov <stepan.koltsov@gmail.com>

On Sun, Jan 10, 2010 at 20:42, Daniel Sobral <dcsobral@gmail.com> wrote:
> Well, there's that little "if" problem.

As I said, duplicate class names are rare, it is not a big problem.

Much bigger problem is a verbose header in each files, that is
necessary to use relative imports with current 2.8 syntax.


> And, then, there's import "a.b._".

It doesn't matter, whether you type "import a.b._" and use class C, or
"import a.b.C" and use class C.


S.

> On Sun, Jan 10, 2010 at 3:30 PM, Stepan Koltsov <stepan.koltsov@gmail.com>
> wrote:
>>
>> On Sun, Jan 10, 2010 at 20:20, Daniel Sobral <dcsobral@gmail.com> wrote:
>> > Let me restate this. I want all my imports to import only what I _think_
>> > it
>> > will be importing.
>>
>> You will import exactly what you want. If you have only only one C
>> class, it will be imported by statement "import a.b.C". Problem with
>> 2.7 is that "import a.c.C" may not import C at all, this problem is
>> solved.
>>
>> S.
>>
>>
>> > On Sun, Jan 10, 2010 at 3:01 PM, Stepan Koltsov
>> > <stepan.koltsov@gmail.com>
>> > wrote:
>> >>
>> >> On Sun, Jan 10, 2010 at 19:42, Daniel Sobral <dcsobral@gmail.com>
>> >> wrote:
>> >> > And how would you go about avoiding importing more than you want?
>> >>
>> >> import _root_.a.b.C imports only _root_.a.b.C
>> >>
>> >> import mycompany.a.b.C imports only _root_.com.mycompany.a.b.C
>> >>
>> >> But precise import is rarely needed, because duplicate class names are
>> >> rare (unlike duplicate package names).
>> >>
>> >> S.
>> >>
>> >>
>> >> > On Sun, Jan 10, 2010 at 2:21 PM, Stepan Koltsov
>> >> > <stepan.koltsov@gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> On Sun, Jan 10, 2010 at 13:18, Johannes Rudolph
>> >> >> <johannes.rudolph@googlemail.com> wrote:
>> >> >> >
>> >> >> >
>> >> >> > http://old.nabble.com/Revisiting-absolute-relative-paths-to24492690.html
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > http://old.nabble.com/Nested-package-scopes-vs.-Imports-%28Was%3A-Revisiting--absolute-relative-paths%29-tp24517644p24518578.html
>> >> >>
>> >> >> Neither link discusses what I want: "import a.b.C" imports C from
>> >> >> one
>> >> >> of _root_.a.b, com.a.b, com.mycompany.a.b, com.mycompany.program.a.b
>> >> >> if only one exists.
>> >> >>
>> >> >> S.
>> >> >>
>> >> >>
>> >> >> > On Sun, Jan 10, 2010 at 4:37 AM, Naftoli Gugenheim
>> >> >> > <naftoligug@gmail.com> wrote:
>> >> >> >> It was a long one, and included Martin Odersky, so that should
>> >> >> >> narrow
>> >> >> >> it down.
>> >> >> >>
>> >> >> >> -------------------------------------
>> >> >> >> Stepan Koltsov<stepan.koltsov@gmail.com> wrote:
>> >> >> >>
>> >> >> >> On Sun, Jan 10, 2010 at 06:31, Naftoli Gugenheim
>> >> >> >> <naftoligug@gmail.com>
>> >> >> >> wrote:
>> >> >> >>> Maybe someone can link to the right thread?
>> >> >> >>
>> >> >> >> You meant there was a thread? And similar proposal was rejected?
>> >> >> >>
>> >> >> >> S.
>> >> >> >>
>> >> >> >>
>> >> >> >>> -------------------------------------
>> >> >> >>> Stepan Koltsov<stepan.koltsov@gmail.com> wrote:
>> >> >> >>>
>> >> >> >>> On Sun, Jan 10, 2010 at 05:58, Naftoli Gugenheim
>> >> >> >>> <naftoligug@gmail.com> wrote:
>> >> >> >>>> Did you search for the discussion? This was all discussed very
>> >> >> >>>> openly
>> >> >> >>>> at length, quite a while ago. After you read the discussion if
>> >> >> >>>> you
>> >> >> >>>> have
>> >> >> >>>> questions ask them, although it's probably too late.
>> >> >> >>>
>> >> >> >>> No, it is not too late, 2.8 even is not beta yet.
>> >> >> >>>
>> >> >> >>> I searched (now), I have found several discussions where 2.7
>> >> >> >>> package
>> >> >> >>> importing mechanism compared to 2.8 mechanism.
>> >> >> >>>
>> >> >> >>> I haven't found a discussion of what I'd like to have: "import
>> >> >> >>> a.b.C"
>> >> >> >>> statement imports from (maybe) several packages.
>> >> >> >>>
>> >> >> >>> S.
>> >> >> >>>
>> >> >> >>>
>> >> >> >>>> -------------------------------------
>> >> >> >>>> Stepan Koltsov<stepan.koltsov@gmail.com> wrote:
>> >> >> >>>>
>> >> >> >>>> On Sun, Jan 10, 2010 at 05:17, jherber <jimherber@gmail.com>
>> >> >> >>>> wrote:
>> >> >> >>>>>
>> >> >> >>>>> what if you thought you were importing
>> >> >> >>>>> com.myco.wrappers.java.io.File (but
>> >> >> >>>>> you had not finished the implementation)?  in your scenario
>> >> >> >>>>> java.io.File
>> >> >> >>>>> would be pulled into scope with no warning or error.  A subtle
>> >> >> >>>>> bug
>> >> >> >>>>> is then
>> >> >> >>>>> introduced.
>> >> >> >>>>
>> >> >> >>>> I said, if both classes match "import java.io.File", no class
>> >> >> >>>> should
>> >> >> >>>> be imported. Attempt to use File identifier should be an error.
>> >> >> >>>>
>> >> >> >>>> Anyway, having several classes with same name in single project
>> >> >> >>>> is
>> >> >> >>>> a
>> >> >> >>>> bad idea. AFAIU, intent of new package importing mechanism is
>> >> >> >>>> to
>> >> >> >>>> protect against duplicate package names, not against duplicate
>> >> >> >>>> class
>> >> >> >>>> names.
>> >> >> >>>>
>> >> >> >>>> I don't understand, why new verbose package declaration syntax
>> >> >> >>>> (that
>> >> >> >>>> also breaks existing code) does not annoy people. Why doesn't
>> >> >> >>>> everyone
>> >> >> >>>> complain? Maybe I miss something...
>> >> >> >>>>
>> >> >> >>>> S.
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>>> What might be nice is for Martin to save our poor fingers and
>> >> >> >>>>> eyes
>> >> >> >>>>> from
>> >> >> >>>>> having "_root_" noise up our code, by allowing "_" to be a
>> >> >> >>>>> placeholder for
>> >> >> >>>>> "_root_" at the beginning of import path.
>> >> >> >>>>>
>> >> >> >>>>> "import _.java.io.File" would imply "import
>> >> >> >>>>> _root_.java.io.File"
>> >> >> >>>>>
>> >> >> >>>>> and
>> >> >> >>>>>
>> >> >> >>>>> "import _.java.io._" would imply "import _root_.java.io._"
>> >> >> >>>>>
>> >> >> >>>>>
>> >> >> >>>>>
>> >> >> >>>>>
>> >> >> >>>>>> Why can't "import java.io.File" import both
>> >> >> >>>>>> _root_.java.io.File
>> >> >> >>>>>> and
>> >> >> >>>>>> com.mycompany.wrappers.java.io.File ? (successfully if at
>> >> >> >>>>>> least
>> >> >> >>>>>> one
>> >> >> >>>>>> exists)
>> >> >> >>>>>
>> >> >> >>>>> I meant "successfully if exacly one of java.io.File and
>> >> >> >>>>> com.mycompany.wrappers.java.io.File avaiable".
>> >> >> >>>>>
>> >> >> >>>>> S.
>> >> >> >>>>>
>> >> >> >>>>>
>> >> >> >>>>>
>> >> >> >>>>> --
>> >> >> >>>>> View this message in context:
>> >> >> >>>>>
>> >> >> >>>>>
>> >> >> >>>>> http://old.nabble.com/package-declaration-syntax-tp27081262p27095040.html
>> >> >> >>>>> Sent from the Scala - User mailing list archive at Nabble.com.
>> >> >> >>>>>
>> >> >> >>>>>
>> >> >> >>>>
>> >> >> >>>
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > Johannes
>> >> >> >
>> >> >> > -----------------------------------------------
>> >> >> > Johannes Rudolph
>> >> >> > http://virtual-void.net
>> >> >> >
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Daniel C. Sobral
>> >> >
>> >> > I travel to the future all the time.
>> >> >
>> >
>> >
>> >
>> > --
>> > Daniel C. Sobral
>> >
>> > I travel to the future all the time.
>> >
>
>
>
> --
> Daniel C. Sobral
>
> I travel to the future all the time.
>

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

On Sun, Jan 10, 2010 at 12:48 PM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

Take it to stackoverflow... The votes will reveal all!

But this isn't really a question any more--it's a debate topic.  I've noticed that those tend to get closed on StackOverflow.  For example:

  http://stackoverflow.com/questions/2017359/disadvantages-of-message-passing-systems-closed
 
"How do I import my class C from my.package in Scala 2.8" is a different sort of thing from "let's debate the nature of the package hierarchy".

I think there are two competing ways to conceive of a package:

(1) A package is like an object ("package object" anyone?).  It has a name that can be in scope, hidden by other names, and so on.

(2) A package is a set of declarations that can be referred to in a common way and conveniently incorporated together ("import collection.mutable._" anyone?).

As far as I can tell, Scala's implementation of packages is much more (1)-like than (2)-like.  This makes constructs like:

import java.util
import my.util.extra
import org.clevercode.java.xml.util.my
import scala.util.regexp

kind of dangerous if they're interpreted as

import java
import util
import my
import util // First java.util is now hidden!
(etc.)

So it's wiser to interpret them as

alias java.util = util
alias my.util.extra = extra

This approach makes resolving

util.List

very straightforward: find the name in scope called "util", see if it has a "List" in it, done.

If you're going to think about it as (2), you need to do something else:

(a) on-the-fly assembly of co-named packages into a map from variable back into the package from whence it came
(b) a look up in a list of all possible packages that share the same name

and then it's less worrying if you import everything along the way, because you'll only have conflicts if two packages with the same name have contents with the same name.

Personally, I think the former is easier to keep track of, though, for really big projects.  Chances are, for a really big project, you *will* have two packages with the same name with contents with the same name.  One of your goals will likely be to keep the namespace as manageable as possible.  One could invent a no-really-just-what-I-asked-for syntax like

import {java=_}.util

to help keep the namespace under control, but I prefer only getting explicitly what you ask for.


  --Rex

On Sun, Jan 10, 2010 at 21:00, Kevin Wright
wrote:
> (Let's try this again, I forgot to reply to all...)
> It's maybe a bit more verbose, but certainly not in a bad way.  These are
> only lines at the top of the file, you can simply scroll past them!
> In addition, this syntax carries extra semantic meaning.  Consider the
> following:
>   package com.mycompany.funkyproject
>   package foo
>   package bar
>   class ...
> It's now made *very* clear that "com.mycompany.funkyproject" is an atomic
> construct being used as a unique namespace, and that that we're not granting
> any special privileges to the `com` package.

You said that new package declaration and importing mechanism is more
powerful that what I've proposed. I agreed with that, but I think that
it is also overcomplicated, all it flexibility is practically not very
useful and it makes Scala using (learning, adoption) harder.

I think that Scala is more complex than even C++, and it is a problem.

S.

> 2010/1/10 Stepan Koltsov
>>
>> On Sun, Jan 10, 2010 at 20:42, Daniel Sobral wrote:
>> > Well, there's that little "if" problem.
>>
>> As I said, duplicate class names are rare, it is not a big problem.
>>
>> Much bigger problem is a verbose header in each files, that is
>> necessary to use relative imports with current 2.8 syntax.
>>
>>
>> > And, then, there's import "a.b._".
>>
>> It doesn't matter, whether you type "import a.b._" and use class C, or
>> "import a.b.C" and use class C.
>>
>>
>> S.
>>
>> > On Sun, Jan 10, 2010 at 3:30 PM, Stepan Koltsov
>> >
>> > wrote:
>> >>
>> >> On Sun, Jan 10, 2010 at 20:20, Daniel Sobral
>> >> wrote:
>> >> > Let me restate this. I want all my imports to import only what I
>> >> > _think_
>> >> > it
>> >> > will be importing.
>> >>
>> >> You will import exactly what you want. If you have only only one C
>> >> class, it will be imported by statement "import a.b.C". Problem with
>> >> 2.7 is that "import a.c.C" may not import C at all, this problem is
>> >> solved.
>> >>
>> >> S.
>> >>
>> >>
>> >> > On Sun, Jan 10, 2010 at 3:01 PM, Stepan Koltsov
>> >> >
>> >> > wrote:
>> >> >>
>> >> >> On Sun, Jan 10, 2010 at 19:42, Daniel Sobral
>> >> >> wrote:
>> >> >> > And how would you go about avoiding importing more than you want?
>> >> >>
>> >> >> import _root_.a.b.C imports only _root_.a.b.C
>> >> >>
>> >> >> import mycompany.a.b.C imports only _root_.com.mycompany.a.b.C
>> >> >>
>> >> >> But precise import is rarely needed, because duplicate class names
>> >> >> are
>> >> >> rare (unlike duplicate package names).
>> >> >>
>> >> >> S.
>> >> >>
>> >> >>
>> >> >> > On Sun, Jan 10, 2010 at 2:21 PM, Stepan Koltsov
>> >> >> >
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> On Sun, Jan 10, 2010 at 13:18, Johannes Rudolph
>> >> >> >> wrote:
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > http://old.nabble.com/Revisiting-absolute-relative-paths-to24492690.html
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > http://old.nabble.com/Nested-package-scopes-vs.-Imports-%28Was%3A-Revisi...
>> >> >> >>
>> >> >> >> Neither link discusses what I want: "import a.b.C" imports C from
>> >> >> >> one
>> >> >> >> of _root_.a.b, com.a.b, com.mycompany.a.b,
>> >> >> >> com.mycompany.program.a.b
>> >> >> >> if only one exists.
>> >> >> >>
>> >> >> >> S.
>> >> >> >>
>> >> >> >>
>> >> >> >> > On Sun, Jan 10, 2010 at 4:37 AM, Naftoli Gugenheim
>> >> >> >> > wrote:
>> >> >> >> >> It was a long one, and included Martin Odersky, so that should
>> >> >> >> >> narrow
>> >> >> >> >> it down.
>> >> >> >> >>
>> >> >> >> >> -------------------------------------
>> >> >> >> >> Stepan Koltsov wrote:
>> >> >> >> >>
>> >> >> >> >> On Sun, Jan 10, 2010 at 06:31, Naftoli Gugenheim
>> >> >> >> >>
>> >> >> >> >> wrote:
>> >> >> >> >>> Maybe someone can link to the right thread?
>> >> >> >> >>
>> >> >> >> >> You meant there was a thread? And similar proposal was
>> >> >> >> >> rejected?
>> >> >> >> >>
>> >> >> >> >> S.
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>> -------------------------------------
>> >> >> >> >>> Stepan Koltsov wrote:
>> >> >> >> >>>
>> >> >> >> >>> On Sun, Jan 10, 2010 at 05:58, Naftoli Gugenheim
>> >> >> >> >>> wrote:
>> >> >> >> >>>> Did you search for the discussion? This was all discussed
>> >> >> >> >>>> very
>> >> >> >> >>>> openly
>> >> >> >> >>>> at length, quite a while ago. After you read the discussion
>> >> >> >> >>>> if
>> >> >> >> >>>> you
>> >> >> >> >>>> have
>> >> >> >> >>>> questions ask them, although it's probably too late.
>> >> >> >> >>>
>> >> >> >> >>> No, it is not too late, 2.8 even is not beta yet.
>> >> >> >> >>>
>> >> >> >> >>> I searched (now), I have found several discussions where 2.7
>> >> >> >> >>> package
>> >> >> >> >>> importing mechanism compared to 2.8 mechanism.
>> >> >> >> >>>
>> >> >> >> >>> I haven't found a discussion of what I'd like to have:
>> >> >> >> >>> "import
>> >> >> >> >>> a.b.C"
>> >> >> >> >>> statement imports from (maybe) several packages.
>> >> >> >> >>>
>> >> >> >> >>> S.
>> >> >> >> >>>
>> >> >> >> >>>
>> >> >> >> >>>> -------------------------------------
>> >> >> >> >>>> Stepan Koltsov wrote:
>> >> >> >> >>>>
>> >> >> >> >>>> On Sun, Jan 10, 2010 at 05:17, jherber
>> >> >> >> >>>> wrote:
>> >> >> >> >>>>>
>> >> >> >> >>>>> what if you thought you were importing
>> >> >> >> >>>>> com.myco.wrappers.java.io.File (but
>> >> >> >> >>>>> you had not finished the implementation)?  in your scenario
>> >> >> >> >>>>> java.io.File
>> >> >> >> >>>>> would be pulled into scope with no warning or error.  A
>> >> >> >> >>>>> subtle
>> >> >> >> >>>>> bug
>> >> >> >> >>>>> is then
>> >> >> >> >>>>> introduced.
>> >> >> >> >>>>
>> >> >> >> >>>> I said, if both classes match "import java.io.File", no
>> >> >> >> >>>> class
>> >> >> >> >>>> should
>> >> >> >> >>>> be imported. Attempt to use File identifier should be an
>> >> >> >> >>>> error.
>> >> >> >> >>>>
>> >> >> >> >>>> Anyway, having several classes with same name in single
>> >> >> >> >>>> project
>> >> >> >> >>>> is
>> >> >> >> >>>> a
>> >> >> >> >>>> bad idea. AFAIU, intent of new package importing mechanism
>> >> >> >> >>>> is
>> >> >> >> >>>> to
>> >> >> >> >>>> protect against duplicate package names, not against
>> >> >> >> >>>> duplicate
>> >> >> >> >>>> class
>> >> >> >> >>>> names.
>> >> >> >> >>>>
>> >> >> >> >>>> I don't understand, why new verbose package declaration
>> >> >> >> >>>> syntax
>> >> >> >> >>>> (that
>> >> >> >> >>>> also breaks existing code) does not annoy people. Why
>> >> >> >> >>>> doesn't
>> >> >> >> >>>> everyone
>> >> >> >> >>>> complain? Maybe I miss something...
>> >> >> >> >>>>
>> >> >> >> >>>> S.
>> >> >> >> >>>>
>> >> >> >> >>>>
>> >> >> >> >>>>> What might be nice is for Martin to save our poor fingers
>> >> >> >> >>>>> and
>> >> >> >> >>>>> eyes
>> >> >> >> >>>>> from
>> >> >> >> >>>>> having "_root_" noise up our code, by allowing "_" to be a
>> >> >> >> >>>>> placeholder for
>> >> >> >> >>>>> "_root_" at the beginning of import path.
>> >> >> >> >>>>>
>> >> >> >> >>>>> "import _.java.io.File" would imply "import
>> >> >> >> >>>>> _root_.java.io.File"
>> >> >> >> >>>>>
>> >> >> >> >>>>> and
>> >> >> >> >>>>>
>> >> >> >> >>>>> "import _.java.io._" would imply "import _root_.java.io._"
>> >> >> >> >>>>>
>> >> >> >> >>>>>
>> >> >> >> >>>>>
>> >> >> >> >>>>>
>> >> >> >> >>>>>> Why can't "import java.io.File" import both
>> >> >> >> >>>>>> _root_.java.io.File
>> >> >> >> >>>>>> and
>> >> >> >> >>>>>> com.mycompany.wrappers.java.io.File ? (successfully if at
>> >> >> >> >>>>>> least
>> >> >> >> >>>>>> one
>> >> >> >> >>>>>> exists)
>> >> >> >> >>>>>
>> >> >> >> >>>>> I meant "successfully if exacly one of java.io.File and
>> >> >> >> >>>>> com.mycompany.wrappers.java.io.File avaiable".
>> >> >> >> >>>>>
>> >> >> >> >>>>> S.
>> >> >> >> >>>>>
>> >> >> >> >>>>>
>> >> >> >> >>>>>
>> >> >> >> >>>>> --
>> >> >> >> >>>>> View this message in context:
>> >> >> >> >>>>>
>> >> >> >> >>>>>
>> >> >> >> >>>>>
>> >> >> >> >>>>> http://old.nabble.com/package-declaration-syntax-tp27081262p27095040.html
>> >> >> >> >>>>> Sent from the Scala - User mailing list archive at
>> >> >> >> >>>>> Nabble.com.
>> >> >> >> >>>>>
>> >> >> >> >>>>>
>> >> >> >> >>>>
>> >> >> >> >>>
>> >> >> >> >>
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > --
>> >> >> >> > Johannes
>> >> >> >> >
>> >> >> >> > -----------------------------------------------
>> >> >> >> > Johannes Rudolph
>> >> >> >> > http://virtual-void.net
>> >> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > Daniel C. Sobral
>> >> >> >
>> >> >> > I travel to the future all the time.
>> >> >> >
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Daniel C. Sobral
>> >> >
>> >> > I travel to the future all the time.
>> >> >
>> >
>> >
>> >
>> > --
>> > Daniel C. Sobral
>> >
>> > I travel to the future all the time.
>> >
>
>
>
> --
> Kevin Wright
>
> mail/google talk: kev.lee.wright@googlemail.com
> wave: kev.lee.wright@googlewave.com
> skype: kev.lee.wright
> twitter: @thecoda
>
>