Visibility of GenTraversableOnce

On 5/6/11 3:19 PM, Daniel Spiewak wrote:
> private[collection] trait GenTraversableOnce[+A]
>
> Words fail me.

So did google, I take it. The situation has been noted.

On Sat, May 7, 2011 at 12:19 AM, Daniel Spiewak <djspiewak@gmail.com> wrote:

private[collection] trait GenTraversableOnce[+A]

Words fail me.  This very effectively makes it impossible to override methods like flatMap outside of the scala.collection package, which is a huge flexibility regression from 2.8 (e.g. I depend on this in Anti-XML).  Considering that TraversableOnce is public, I see no reason why GenTraversableOnce should be package-private in this way.

Yes, that was a blunder. The main reason is that we start to push hard on the limits of human comprehension in what concerns the number of supertraits in ScalaDoc. We thought we could hide a few by making them private[scala]. But obviously that won't work if the type appears in a public interface somewhere. We'll fix it for the next RC. Should be close to final now.

Cheers

 -- Martin

Hi,

On 7 May 2011 10:05, martin odersky <martin.odersky@epfl.ch> wrote:

 We thought we could hide a few by making them private[scala]. But obviously that won't work if the type appears in a public interface somewhere. We'll fix it for the next RC. Should be close to final now.

Cheers

 -- Martin

Are there any situations where it makes sense for something with scoped privacy to leak out through a publicly visible member? If not, is it something the compiler should catch?
Matthew

--
Matthew Pocockmailto: turingatemyhamster@gmail.comgchat: turingatemyhamster@gmail.com msn: matthew_pocock@yahoo.co.ukirc.freenode.net: drdozer(0191) 2566550

On 5/9/11 3:48 PM, Matthew Pocock wrote:
> Are there any situations where it makes sense for something with scoped
> privacy to leak out through a publicly visible member? If not, is it
> something the compiler should catch?

Way ahead of you. Already implemented warning. Turns out it's really
noisy in its naive form, so I can't check it in without refining the
check a ways further.

One problem is that I sometimes do stuff like this:

private[process] object processInternal {
type File = java.io.File
}

OK, that saves me from having to import java.io.File all over the place,
I can import all the stuff in that object and be done. (Can't just put
the alias in the package object because of #3160 and #3836.) But then we
have this:

trait FileBuilder extends Sink with Source {
def #<<(f: File): ProcessBuilder
def #<<(u: URL): ProcessBuilder
def #<<(i: => InputStream): ProcessBuilder
def #<<(p: ProcessBuilder): ProcessBuilder
}

Now you can implement that method #<< with java.io.File. But to the
casual compiler observing, it looks like you are leaking a private type
through a public interface. And then it gets really interesting if only
one or the other of the aliased type or the normalized type has a
reference to a type with limited access.