lazy vals and public bitmap$n field

On 22 November 2010 16:04, Heiko Seeberger <heiko.seeberger@googlemail.com> wrote:

Hi,
When using CDI, the new rockstar in Java EE, lazy vals are no good citizens and make using Scala very hard (Who would like to do without lazy vals?). The reason is, that CDI (at least Weld, the reference implementation) does not like public fields for objects it has to create a proxy for. Therefore I would like to ask whether there is a chance that there are no public fields used to implement lazy vals in the future?
Thanks,
Heiko

As a workaround... How well does it work if you hide them inside a nested singleton?
class Foo {   private[this] object Private {    lazy val x = ...    lazy val y = ...  }  import Private._
  ...} 

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

On Mon, Nov 22, 2010 at 05:06:44PM +0000, Kevin Wright wrote:
> As a workaround... How well does it work if you hide them inside a
> nested singleton?

I think he's talking about the bitmap$n fields, which as of 2.8.1 are
public regardless of the visibility of the lazy val. (In trunk this has
changed, but I don't know if far enough to solve the issue.)

On Mon, Nov 22, 2010 at 5:04 PM, Heiko Seeberger <heiko.seeberger@googlemail.com> wrote:

Hi,
When using CDI, the new rockstar in Java EE, lazy vals are no good citizens and make using Scala very hard (Who would like to do without lazy vals?). The reason is, that CDI (at least Weld, the reference implementation) does not like public fields for objects it has to create a proxy for. Therefore I would like to ask whether there is a chance that there are no public fields used to implement lazy vals in the future?

OTOH I don't know if there's any real reason for having them public, other than Scala generally having troubles keeping access modifiers in check. They're for sure protected in the compiler's mind, so maybe the backed could do a better job at emitting them as such (we don't go through getters/setters for synthetics, like bitmap fields).
iulian 

Thanks,
Heiko

Company: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net
Akka - Simpler Scalability, Fault-Tolerance, Concurrency & Remoting through Actors: akkasource.org

--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais

iulian dragos wrote:
>
> OTOH I don't know if there's any real reason for having them public,
> other than Scala generally having troubles keeping access modifiers in
> check. They're for sure protected in the compiler's mind, so maybe the
> backed could do a better job at emitting them as such (we don't go
> through getters/setters for synthetics, like bitmap fields).
>
> iulian
>

That sounds similar to #3770 where some flag is left behind. I guess
create a ticket and we will have a look. Note that with current state of
the trunk, where nested objects are transformed to lazy vals this may
become a bigger issue for you.

Thanks,
hubert

On Mon, Nov 22, 2010 at 06:17:53PM +0100, iulian dragos wrote:
> OTOH I don't know if there's any real reason for having them public,
> other than Scala generally having troubles keeping access modifiers in
> check. They're for sure protected in the compiler's mind, so maybe the
> backed could do a better job at emitting them as such (we don't go
> through getters/setters for synthetics, like bitmap fields).

Last I checked (which was like a week ago) scala never emits protected
fields, only private or public.

if (isConsideredPrivate) ACC_PRIVATE else ACC_PUBLIC,

I'm sure it will be tedious dicey work trying to make it more granular.

On Mon, Nov 22, 2010 at 6:29 PM, Paul Phillips <paulp@improving.org> wrote:

On Mon, Nov 22, 2010 at 06:17:53PM +0100, iulian dragos wrote:
> OTOH I don't know if there's any real reason for having them public,
> other than Scala generally having troubles keeping access modifiers in
> check. They're for sure protected in the compiler's mind, so maybe the
> backed could do a better job at emitting them as such (we don't go
> through getters/setters for synthetics, like bitmap fields).

Last I checked (which was like a week ago) scala never emits protected
fields, only private or public.

 if (isConsideredPrivate) ACC_PRIVATE else ACC_PUBLIC,

I'm sure it will be tedious dicey work trying to make it more granular.

Why can't we just emity ACC_PROTECTED for protected access?

Cheers

 -- Martin

On Mon, Nov 22, 2010 at 06:47:18PM +0100, martin odersky wrote:
> Why can't we just emity ACC_PROTECTED for protected access?

It isn't that we can't emit it, it's that by the time bytecode is being
generated it doesn't know whether it is safe to do so, because of inner
classes being flattened and maybe other reasons too. There is some
subset of cases where it could be done, but it would take work to
achieve them and it will still fail to solve the problem: the jvm
enforces the protected flag in a manner incompatible with scala
protected access semantics.

Java deals with it by creating accessor methods in outer classes for use
by inner classes. We could do that too, right? It seems like it'd be
about the same code already used for superaccessors.

Here is the commit where ACC_PROTECTED stopped being emitted:

http://lampsvn.epfl.ch/trac/scala/changeset/8379

The commit message and immediate context probably says it all:

"Added InnerClasses? attribute in classfiles"

+/* jf = jf | (if (sym hasFlag Flags.PRIVATE) ACC_PRIVATE else
+ if (sym hasFlag Flags.PROTECTED) ACC_PROTECTED else ACC_PUBLIC);
+*/
+ jf = jf | (if (sym hasFlag Flags.PRIVATE) ACC_PRIVATE else ACC_PUBLIC);

On Mon, Nov 22, 2010 at 7:11 PM, Paul Phillips <paulp@improving.org> wrote:

On Mon, Nov 22, 2010 at 06:47:18PM +0100, martin odersky wrote:
> Why can't we just emity ACC_PROTECTED for protected access?

It isn't that we can't emit it, it's that by the time bytecode is being
generated it doesn't know whether it is safe to do so, because of inner
classes being flattened and maybe other reasons too.  There is some
subset of cases where it could be done, but it would take work to
achieve them and it will still fail to solve the problem: the jvm
enforces the protected flag in a manner incompatible with scala
protected access semantics.

That is true. We do have code in place for emitting protected accessors, but it needs a bit of work before it can be relied on. Currently, it handles Java protected members pretty well. One tricky issue has to do with self types, if I remember correctly: any class may declare a self type and expect to access protected members in that class. 
trait Foo {  protected val x = "abc" }
class Bar { self: Foo =>   println(x)}
However, at the bytecode level there is no subtype relationship between Bar and Foo (and they may well be in different packages). That means there is no place where a protected accessor can be added when compiling Bar. One way out is what Paul suggest, to use the super accessor mechanism: add abstract accessors in Bar, and implement them when Bar is instantiated or mixed in with something that satisfies the self-type requirement. The current protected accessor code is simpler than that (only adds concrete accessors), so more work is needed. Probably it's not that hard, given the super accessors do something very similar.
iulian 

Java deals with it by creating accessor methods in outer classes for use
by inner classes.  We could do that too, right? It seems like it'd be
about the same code already used for superaccessors.

Here is the commit where ACC_PROTECTED stopped being emitted:

 http://lampsvn.epfl.ch/trac/scala/changeset/8379

The commit message and immediate context probably says it all:

"Added InnerClasses? attribute in classfiles"

+/*      jf = jf | (if (sym hasFlag Flags.PRIVATE) ACC_PRIVATE else
+                  if (sym hasFlag Flags.PROTECTED) ACC_PROTECTED else ACC_PUBLIC);
+*/
+      jf = jf | (if (sym hasFlag Flags.PRIVATE) ACC_PRIVATE else  ACC_PUBLIC);

--
Paul Phillips      | Christ died for our sins.  Dare we make his martyrdom
Caged Spirit       | meaningless by not committing them?
Empiricist         |     -- Jules Feiffer
ha! spill, pupil   |----------* http://www.improving.org/paulp/ *----------

--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais