default java access

Thanks for forwarding to the list, Paul!

On Tue, Mar 31, 2009 at 8:36 PM, Paul Phillips wrote:
> Hi internals! It looks like martin slightly typoed the list name and I
> propagated it into my replies, so here are three messages which were
> intended for all 2 or 3 of you but entered Mail Delivery Subsystem land
> instead.
>
>
> Date: Tue, 31 Mar 2009 20:06:13 +0200
> From: martin odersky
> To: Paul Phillips , scala-internalsl@epfl.ch
> Subject: r17416
>
> Hi Paul,
>
> I still don't understand the logic behind the fixes to 1240 and 1840.
> If defaultAcess is true, that is, if no private/protected/public is given,
> you set the flag to PROTECTED. Why? That seems to go too far.
> Also I don't understand why empty package should be treated specially here.
>
> Cheers
>
>  -- Martin
>
>
>
> From: Paul Phillips
> To: martin odersky
> Cc: scala-internalsl@epfl.ch
> Subject: Re: r17416
>
> On Tue, Mar 31, 2009 at 08:06:13PM +0200, martin odersky wrote:
>> I still don't understand the logic behind the fixes to 1240 and 1840.
>> If defaultAcess is true, that is, if no private/protected/public is
>> given, you set the flag to PROTECTED. Why? That seems to go too far.
>
> In java, if no access modifier is specified, the access level is
> supposed to be "package protected", right? Unless I'm still off the deep
> end about what everything means, this would expressed in scala for
> package p as
>
>  protected[p] def f()
>
No, it's

private[p] def f()

That is, no flag set, privateWithin set to enclosing package.

>> Also I don't understand why empty package should be treated specially
>> here.
>
> It shouldn't, thus the XXX comment; but if it isn't treated specially,
> scala code with no package cannot access default-access java code with
> no package.  I think this is a result of one or more bugs elsewhere in
> how the empty package is represented, but if I'm wrong about how default
> access is to be represented then none of my thoughts here will have any
> basis in reality.
>
I see. That might have to do with the fact that in JavaParsers we can
only give a name
for privateWithin, not a symbol. And the empty name already signifies
no privateWithin.
So we'd have use EmptyPackage.name instead.

Cheers

On Tue, Mar 31, 2009 at 08:46:39PM +0200, martin odersky wrote:
> No, it's
>
> private[p] def f()
>
> That is, no flag set, privateWithin set to enclosing package.

This day has been a struggle...

On Tue, Mar 31, 2009 at 12:03:46PM -0700, Paul Phillips wrote:
> OK -- if I do it that way, #1240 does not work. In fact that's just how
> it was when I set out to fix #1240.

OK, that much is true:

> Scala code cannot access java code in the same package, if no flag is
> set and privateWithin is set to the package on the java member.

That however is me misremembering what 1240 was.