The Artima Developer Community
Sponsored Link

Java Community News
Ted Neward on Scala Classes

6 replies on 1 page. Most recent reply: Feb 23, 2008 8:50 AM by Chris Dutton

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 6 replies on 1 page
Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

Ted Neward on Scala Classes Posted: Feb 21, 2008 4:12 PM
Reply to this message Reply
Summary
Scala aims to combine object-oriented and functional programming. In a recent IBM developerWorks article, Ted Neward discusses the similarities and differences between Java and Scala classes.
Advertisement

Ted Neward had recently started an article series on IBM's developerWorks site devoted to introducing Java developers to the Scala language. The most recent article in the series, Class Action, compares Java and Scala classes.

Neward notes that:

Scala's functional programming features are compelling, but they're not the only reason Java developers should be interested in the language. In fact, Scala blends functional concepts and object orientation. In order to let the Java-cum-Scala programmer feel more at home, it makes sense to look at Scala's object features and see how they map over to Java linguistically. Bear in mind that there isn't a direct mapping for some of these features, or in some cases, the "mapping" is more of an analog than a direct parallel.

Among other examples, Neward presents a simple POJO or, rather, a plain, old Scala object, that illustrates the conciseness of the Scala language:

class Person(firstName:String, lastName:String, age:Int) {
    def getFirstName = firstName
    def getLastName = lastName
    def getAge = age

    override def toString =
        "[Person firstName:" + firstName + " lastName:" + lastName +
            " age:" + age + " ]"
}

Neward points out, for example, Scala's ability to pass parameters to a default constructor:

Scala's preference for a single constructor makes a certain kind of sense—most classes end up having a single constructor or a collection of constructors that all "chain" through a single constructor as a convenience... Scala's constructor chain does the usual Java-constructor-chaining thing by calling into the preferred constructor...

Another feature Neward points to is the override keyword and the way a method returns values in Scala:

The override keyword in the front of the definition is required so that Scala can check to make sure that a corresponding definition exists in the base class. This can help prevent subtle bugs created by accidental keyboard slips...

Notice, as well, that the return type is not specified—it's obvious from the definition of the method body—and that the returned value isn't explicitly denoted using the return keyword, which Java would require. Instead, the last value in the function is considered the return value implicitly..

In the article, Neward also describes properties in a Scala class, function definitions, and the meaning of the var keyword.

What do you think of the manner in which Scala allows you to simplify class definitions?


Arnold deVos

Posts: 18
Nickname: arnoldd
Registered: Dec, 2002

Re: Ted Neward on Scala Classes Posted: Feb 21, 2008 6:02 PM
Reply to this message Reply
I found this passage confusing:

"The Rational class still has three private fields, n, d, and g, but they are hidden from the world by default private access in the case of n and d ....".

Actually, n and d are constructor parameters.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Ted Neward on Scala Classes Posted: Feb 22, 2008 10:45 AM
Reply to this message Reply
> I found this passage confusing:
>
> "The Rational class still has three private fields, n, d,
> and g, but they are hidden from the world by default
> private access in the case of n and d ....".
>
> Actually, n and d are constructor parameters.

Forgive me if I get the technicalities wrong here but the parameters to the constructor are implicitly available as private members.

Arnold deVos

Posts: 18
Nickname: arnoldd
Registered: Dec, 2002

Re: Ted Neward on Scala Classes Posted: Feb 22, 2008 4:14 PM
Reply to this message Reply
> Forgive me if I get the technicalities wrong here but the
> parameters to the constructor are implicitly available as
> private members.

After some experimentation, the answer seems to be yes and no. If you expose a parameter with a getter or otherwise use it in a method, then yes, it becomes a field at the bytecode level.

But in the example, parameters n and d are not required after construction and the compiler does not create fields for them. (As seen in the decompiled bytecode listing.)

You could say this is just an optimisation. But if it can be relied upon, it gives the programmer control of what fields will become part of an object without constraining the primary ctor parameter list.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Ted Neward on Scala Classes Posted: Feb 22, 2008 6:11 PM
Reply to this message Reply
> > Forgive me if I get the technicalities wrong here but
> the
> > parameters to the constructor are implicitly available
> as
> > private members.
>
> After some experimentation, the answer seems to be yes and
> no. If you expose a parameter with a getter or otherwise
> use it in a method, then yes, it becomes a field at the
> bytecode level.

I thought that was the way it works which is why I said they were 'available'. And yes, I think the idea is that they are optimized away if they are not used after construction.

One thing to note is that the way the code is structured, these look more like parameters to the class and not a constructor, per se.

Arnold deVos

Posts: 18
Nickname: arnoldd
Registered: Dec, 2002

Re: Ted Neward on Scala Classes Posted: Feb 22, 2008 7:10 PM
Reply to this message Reply
Yes its better to think of them as class parameters rather than ctor parameters. That they might or might not be promoted to members is a subtlety that might be important if you are being careful with the lifetime of the referenced objects or trying to create a lightweight class.

Chris Dutton

Posts: 15
Nickname: cdutton
Registered: Jul, 2004

Re: Ted Neward on Scala Classes Posted: Feb 23, 2008 8:50 AM
Reply to this message Reply
I find it useful (though I am uncertain if it's accurate) to think of Scala classes in the same way I think about closures when it comes to functions.

Another language that behaves much the same way with regards to object creation is O'Caml. Whether Martin Odersky was influenced by O'Caml, I cannot say.

Flat View: This topic has 6 replies on 1 page
Topic: Adobe Releases Flex 3, FlexBuilder 3 Previous Topic   Next Topic Topic: Typesafe Ranged Integers in Scala

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use