Here is a great cheat sheet for Scala Features:

From the structural perspective, next level after project, source folder, library and package is a class.
Class in Java and most other OO language is a happy place where the little ones feel them self at home. With the little ones I mean class members like methods and fields. They represent behavior/state.

The definition of the members is pretty strict in most of the OO languages.
For example in Java we define a class which is identified by a name. And inside this definition we have methods and fields (You can also define nested classes etc.. but I will skip this at the moment). There are special methods that hold the same name as the class. We call this methods Constructors. A method may have a name, return type and a list of parameters. This organization is strict and must be followed!

Not in Scala it don’t.

In Scala a class is also a place for the little ones and it also have a name but the way you define class and it members may variate.

The minimalistic definition of class is:

class Person

this representation is almost useless except when you start to play around with traites, but this I will cover in a different post.

So lets add some members – behavior and state to the old good Person.

class Person(firstName:String, lastName:String)

What you see right here is a primary constructor. It is a class member but with no explicit definition. You can also make this member private.

class Person private (firstName:String, lastName:String)

But this member is not only defined implicitly it also do some implicit stuff. It’s usual to store constructor parameters as private final fields. The notation above does actually this usual thing. This otherwise means that it defines three members – a constructor and two private final fields.
You can convert the private fields to public by defining them as vals.

class Person(val firstName:String, val lastName:String)

And this guys also may lose there immutability if they are defined as vars

class Person(var firstName:String, var lastName:String)

A class may also have a parent class and a constructor may call a super constructor.

class Person(firstName:String, lastName:String) extends Creature(firstName+lastName)

Wait aren’t constructors methods? Shouldn’t they define behavior? Well if you want to define a behavior/side effects, then you have to go an extra mile and create a scope (class body) and then you can just write down the behavior directly in there.

class Person(firstName:String, lastName:String){
 println(firstName + " " + lastName)

By the way Scala has a build in parameter validator require which throws IllegalArgumentException if you’v been bad.

Now in the class body you not only may define the behavior for primary constructor, but also other members.
So you also may define fields traditionally.

class Person(firstName:String, lastName:String){
 var age : Int

The age is a public field (btw. in Scala elements are public by default). A method may be defined in a class body as well but I will skip it, because I want to cover methods/functions/closure sometimes later, and in depth ;) .

What I still want to mention before I speculate about possible IDE support is auxiliary constructor. Scala do have a method overloading and as constructor is a method, it may be overloaded. There are still hard restrictions for constructor overloading in Scala. An auxiliary constructor must make direct or transitive (trough another constructor) call on primary constructor.

class Person private (firstName:String, lastName:String){
 def this() = this("Elvis", "Presley")

The example above demonstrates an auxiliary constructor that calls a private primary constructor and creates an Elvis imitator. The class is a complete bollocks, but I think you get the idea.

And we are still not done. A class may be abstract. This means that it has methods that provide no implementation, this also means that an abstract class should not be instantiated. An abstract class may be extended by other classes and this is pretty much useful for case classes. But what are case classes. Case classes are classes that are primarily used for pattern matching. And because of pattern matching you may define an abstract class sealed. Sealed class means, that extended case classes may only appear in the same file. I will cover pattern matching in another post, but what is still interesting in this post is class extension/inheritance.

What is class inheritance good for?

Well there are two main applications for inheritance:

1. If you extend a class you get his non private members. You may also override his members and than call them in your own implementation.
2. Inheritance is an IS-A relation, this means that the child class is of the same type as its parent. In an example above we could say Person is a Creature so if I need a Creature, I will also be satisfied with a Person, because person is a creature.

I may forbid inheritance by defining a class final.

Now I guess we are ready to talk about IDE support.

Well first of all how do we get to create a class?

Normally a class wizard creates a new file, but in Scala it is optional as we learned before in this post and in (Files and Folders). So feature complete wizard should provide following options:
1. What file you want to place it, a new one or a selected one.
2. Define package identifier
3. Define class name
4. Provide list of parameters for primary constructor.
5. Mark the class as abstract, sealed abstract, final or case class
6. Define class visibility
7. Define parent. By the way in Scala class may extend another non final class, abstract class or a trait. If extended class has a primary constructor wizard may guess how to invoke it or at least provide a todo and nil as parameters.
8. Define a list of mixins/traits. The trait order is important.

Now let’s think about visualizations:

Class outline should show all members of class itself, his parents and mixed in traits.
Primary constructor should be marked as such. Abstract methods also should be marked.

It is pretty complicated thanks to the usage of multiple traits and transitive inheritance relation.

Another interesting field of application is member representation conversion or refactoring. As you may represent the members in different ways, it should be possible to convert one representation in to other.

I sugest the list of possible IDE features is not complete but at this moment the post is long enough :)

Next post will be a step deeper into structural paradigm. It’s going to be all about functions/closures/methods

The first thing one do when want to program is starting a new project.
In the fancy Scala world one can also use REPL, but this is not on the menu in this blog.

So what do we do in traditional way – structurally speaking?

Well, we create a project, this means that we, or our beloved IDE, creates a folder for a project. Than it creates a source folder and a folder for each package we define. If we want to create a class, a file must be created that represent this class.

Not every OO language has this strict rule:
one class = one file and package = folder
But many of them.

It makes things also much easier for IDE because than the logical structure of your program is equal to resource structure of your code. And every file is a compilation unit. So if you want to find a class find a file with the same name.

Now lets see how the genius deal with this kind of problem.

In the book “Programming in Scala (2nd edition)” chapter 13, you can find everything that you need to know about packages, and there is also a very cute example in listing 13.5 where it is possible to represent a pretty complex package structure in two files.

Why the heck somebody need such a messy thing?

Well at first we should realize that the binary produced from this two source files will be well structured, because you may be messy but the compiler won’t.

Now just imagine:
You creating a new project, creating a new source folder and before you start to propagate files and folders as a rabbit, you just create one file and draft the logical structure of your application in it. It is like drawing UML, or describing your project structure in a JSON like style.

You certainly can’t leave all classes in one file because its going to grow as mad, but for initial draft it feels pretty cool.

What also would be pretty cool is, if we had a file decomposition feature in the IDE. This way we could start with one file and than split it into many files in different directories when we need structure on resource level.

Another feature that is crucial for an IDE, that wants to support such a rich code organization feature, is to provide two perspectives on the code. One perspective from the resource point of view where you browse through files and not classes / packages. Another to represents structural/logical view on the project. But I guess this feature is already supported by the major IDEs in one or another way.

It’s done!
I created a new category in my blog and I hope I’ll be patient enough to make a nice series out of it.

Now strait to the title:

Only the stupid need organization, the genius controls the scala..os.

If you don’t recognize it, it is a quote of Albert Einstein.

Only the stupid need organization, the genius controls the chaos.

I guess you can image what it is all about, but still:

In this series I will try to make a mix presentation of Scala features, how they deflect from the traditional ones and what would I expect from an enhanced IDE.

I sad I will try because at the moment I am the stupid one using Java that gives me strict organization. I want to go genius with Scala, but when I read Scala I am getting confused and IDE don’t give me the support I hope.

So this series is going to be my personal path towards brighter future, dreams and how awesome the world could be if we had a proper IDE support. (inception ;) )

© 2011 Max Blog Suffusion theme by Sayontan Sinha