Constructor arguments with same name as super fields

Hello Trond,
I agree that there it seems to be something not right.
I was playing a little bit with your example and I got it to work correctly by (re)defining the `rename`method as follows:
class B(name: String) extends A(name){    def rename(name: String) {      this.name_=(name)    }}
Basically, I'm explicitly calling the setter method for the `name`member of the super class, which is what you expect would (implicitly) happen when you use the assignment symbol on `name` (as you did in your snippet of code). 
Then I tried to assign `name`out of the scope of class B, and it worked like a charm :)

IMO, this is a bug.

Here is the main object that I used for testing
object Main extends Application {  val b = new B("foo")  assert(b.name == "foo")  b.rename("bar")  assert(b.name == "bar")  b.name = "asd"               // this actually works!  assert(b.name == "asd")}


Cheers,  Mirco

On Feb 24, 2009, at 5:43 PM, Trond Olsen wrote:

Are there restrictions on reusing constructor argument names that clash with super fields?

The following fragment:
class A(var name: String)

class B(name: String) extends A(name)
{
    def rename(name: String) { this.name = name }
}

gives this compiler error:
error: reassignment to val
   def rename(name: String) { this.name = name }

In your case, this.name refer to name that was redeclared as val at: class B(/*val*/ name: String). When you do class B(name: String), the B has now a field val name.

In class A the name field is var and in class B is val. I guess the compiler handle it as two distinct fields, one of A and another of B. When you do this.name in B, the B.name is used.

So, the problem is not by constructor argument names, but fields with the same name in child and base class. And I think there's no way do access super fields in that case....


[]s
Victor


On Tue, Feb 24, 2009 at 8:43 PM, Trond Olsen <tolsen77@gmail.com> wrote:

Are there restrictions on reusing constructor argument names that clash with super fields?

The following fragment:
class A(var name: String)

class B(name: String) extends A(name)
{
    def rename(name: String) { this.name = name }
}

gives this compiler error:
error: reassignment to val
   def rename(name: String) { this.name = name }

--
GNU/Linux user #5f5f5f - http://counter.li.org

Is that to say that there are no such things as constructor arguments in Scala as they always get interpreted as fields?

On Wed, Feb 25, 2009 at 5:33 AM, Victor Mateus Oliveira <rhapsodyv@gmail.com> wrote:

In your case, this.name refer to name that was redeclared as val at: class B(/*val*/ name: String). When you do class B(name: String), the B has now a field val name.

In class A the name field is var and in class B is val. I guess the compiler handle it as two distinct fields, one of A and another of B. When you do this.name in B, the B.name is used.

So, the problem is not by constructor argument names, but fields with the same name in child and base class. And I think there's no way do access super fields in that case....


[]s
Victor


On Tue, Feb 24, 2009 at 8:43 PM, Trond Olsen <tolsen77@gmail.com> wrote:

Are there restrictions on reusing constructor argument names that clash with super fields?

The following fragment:
class A(var name: String)

class B(name: String) extends A(name)
{
    def rename(name: String) { this.name = name }
}

gives this compiler error:
error: reassignment to val
   def rename(name: String) { this.name = name }

--
GNU/Linux user #5f5f5f - http://counter.li.org

On Wed, Feb 25, 2009 at 04:47:22PM +0100, Trond Olsen wrote:
> Is that to say that there are no such things as constructor arguments in
> Scala as they always get interpreted as fields?

No, they are only (supposed to be) interpreted as fields if they are used outside of the constructor, or if declared as val. For
instance:

class A(x: Int) { }
class B(x: Int) { val y = x }
class C(x: Int) { def z() = x }

// jp is an alias to look at the bytecode
$ jp A |grep private
$ jp B |grep private
private final int y;
$ jp C |grep private
private final int x;

The third class has to hang onto x so z() can access it. In your example:

class A(var name: String)
class B(name: String) extends A(name) { // skipping rename for now }

A gets a name field, but B has no fields of its own, so it's working as expected in that form. I also think that "def
rename(name: String) { this.name = name }" should result in the method param shadowing the constructor param and thus compile as
you gave it, but it doesn't surprise me much that it doesn't.

It wasn't as much as the rename method that confused me. I wasn't aware that the methods you define within a class can reference constructor arguments, thereby making them into fields.

Your case with the setter it perhaps still valid, as you havn't referenced the constructor arguments, thereby avoiding making it an attribute.

On Wed, Feb 25, 2009 at 5:36 AM, Mirco Dotta <mirco.dotta@gmail.com> wrote:

Hello Trond,
I agree that there it seems to be something not right.
I was playing a little bit with your example and I got it to work correctly by (re)defining the `rename` method as follows:
class B(name: String) extends A(name){    def rename(name: String) {      this.name_=(name)    } }
Basically, I'm explicitly calling the setter method for the `name`member of the super class, which is what you expect would (implicitly) happen when you use the assignment symbol on `name` (as you  did in your snippet of code). 
Then I tried to assign `name`out of the scope of class B, and it worked like a charm :)

IMO, this is a bug.

Here is the main object that I used for testing
object Main extends Application {  val b = new B("foo")  assert(b.name == "foo")   b.rename("bar")  assert(b.name == "bar")  b.name = "asd"               // this actually works!   assert(b.name == "asd")}


Cheers,  Mirco

On Feb 24, 2009, at 5:43 PM, Trond Olsen wrote:

Are there restrictions on reusing constructor argument names that clash with super fields?

The following fragment:
class A(var name: String)

class B(name: String) extends A(name)
{
    def rename(name: String) { this.name = name }
}

gives this compiler error:
error: reassignment to val
   def rename(name: String) { this.name = name }

.hmmessage P { margin:0px; padding:0px } body.hmmessage { font-size: 10pt; font-family:Verdana } I have a large Java program that can be considered a sort of application server.  I'm planning on refactoring it to use OSGI to clean up the application lifecycle.  I'd also like to be able to ake it easy to deploy applications written in Scala and also to rewrite soe parts of it in Scala to see whether the use of the actors model will make it scale better.

 

If anyone could point me towards good info or examples of integrating Java and Scala via OSGI I'd be really grateful.

 

Thanks,

 

- Paul

 

Let ninemsn property help. Need a new place to rent, share or buy?

Hi Paul,

I can't answer to the use of actors in OSGi but what I have seen is
that there were some issues with custom classloaders being used in the
actors codebase (based on a number of previous posts on the lists),
which *could* cause problems with OSGi.

Regarding Scala with OSGi, it works the same as java does, Declarative
Services works fine for most function definitions and I imagine that
Spring DM also works normally.

On the straight OSGi front, it provides some really good primitives
for life cycle management and for code organisation (via the service
registry), its well worth playing with even if you don't use it. I
would advise however that you prefer DS to manually working with the
service registry, as it takes care of many of the common tasks
required (doesn't ease all the pain of thread safety and race
conditions but it trully does help).

cheers,
Chris

On Wed, Mar 4, 2009 at 1:03 AM, Paul Runyan wrote:
> I have a large Java program that can be considered a sort of application
> server.  I'm planning on refactoring it to use OSGI to clean up the
> application lifecycle.  I'd also like to be able to ake it easy to deploy
> applications written in Scala and also to rewrite soe parts of it in Scala
> to see whether the use of the actors model will make it scale better.
>
>
>
> If anyone could point me towards good info or examples of integrating Java
> and Scala via OSGI I'd be really grateful.
>
>
>
> Thanks,
>
>
>
> - Paul
>
>
>
> ________________________________
> Let ninemsn property help. Need a new place to rent, share or buy?

I did it some time ago. Registering an instance of scala.actors.Actor as a OSGi service went OK. (I was using Equinox OSGi).
When used with the DSL (you can find it on the google code AFAIR) for querying for a service, it looked really nice.
I didn't try RemoteActors, but added R-OSGi to that cake and was amazed, becouse it felt like magic:  With about 10 lines of code I was able to query for an actor that had specific properties set, send it a computation request (ordinary case class), which was transmitted in serialized form and the computation was done on remote node in my office. 
Maybe I should find that code and blog about it... 
Szymon 

On Thu, Mar 5, 2009 at 10:57 AM, Chris Twiner <chris.twiner@gmail.com> wrote:

Hi Paul,

I can't answer to the use of actors in OSGi but what I have seen is
that there were some issues with custom classloaders being used in the
actors codebase (based on a number of previous posts on the lists),
which *could* cause problems with OSGi.

Regarding Scala with OSGi, it works the same as java does, Declarative
Services works fine for most function definitions and I imagine that
Spring DM also works normally.

On the straight OSGi front, it provides some really good primitives
for life cycle management and for code organisation (via the service
registry), its well worth playing with even if you don't use it.  I
would advise however that you prefer DS to manually working with the
service registry, as it takes care of many of the common tasks
required (doesn't ease all the pain of thread safety and race
conditions but it trully does help).

cheers,
Chris

On Wed, Mar 4, 2009 at 1:03 AM, Paul Runyan <paul_runyan@hotmail.com> wrote:
> I have a large Java program that can be considered a sort of application
> server.  I'm planning on refactoring it to use OSGI to clean up the
> application lifecycle.  I'd also like to be able to ake it easy to deploy
> applications written in Scala and also to rewrite soe parts of it in Scala
> to see whether the use of the actors model will make it scale better.
>
>
>
> If anyone could point me towards good info or examples of integrating Java
> and Scala via OSGI I'd be really grateful.
>
>
>
> Thanks,
>
>
>
> - Paul
>
>
>
> ________________________________
> Let ninemsn property help. Need a new place to rent, share or buy?

--
ʎɐqǝ uo pɹɐoqʎǝʞ ɐ ʎnq ı ǝɯıʇ ʇsɐן ǝɥʇ sı sıɥʇ

On 03/05/2009 02:29 AM, Szymon Jachim wrote:
> I didn't try RemoteActors, but added R-OSGi to that cake and was
> amazed, becouse it felt like magic:
> With about 10 lines of code I was able to query for an actor that
> had specific properties set, send it a computation request (ordinary
> case class), which was transmitted in serialized form and the
> computation was done on remote node in my office.
>
> Maybe I should find that code and blog about it...
Please do! I've often wanted more meaningful, concrete examples of both
OSGi and Actors and haven't had much luck finding them.

-0xe1a