Suggestions to keep track of for possible improvements

The closures stuff

The entry on ScalaClosures is really about passing by name. Need to differentiate the two (wasn’t intitially clear to me why that was)

From a guy on the scala mailing list

Basics

- Methods – you go over too quickly in my opinion, it is also not

true that they are always defined using an equals sign, if the method
does not return a value you can(should) leave it out.
– Operators – the same problem here.First of all I would put it
after the “loose method calling” so people will already
know/understand when you talk about leaving out the dots and the
parens. Secondly I would give some kind of example because it’s hard
to visualize when you’re not used to operator overloading.
– Symbols – “a string that is always equal to itself” sounds very
confusing even if it’s technically correct (is it?).

In the “bad” section there are several things that have “logical”
explanations (you might still whish things were different of course)
but better people than me could give you far better explanations than
I ever could so I won’t go into them.

Unified Types:

“Every object is a subtype of Any, however in practice, most objects
will be a subtype of AnyRef.” – Confusing, sounds contradictory.
AnyRef being a subtype of Any means that those objects will still be
subtypes of Any.

“thank GOD we don’t need Java’s stupid primitive types any more” – you
might want to remind $deity that under the hood the Java primitive
types still exist, with their advantages (speed/size) and
disadvantages (boxing/unboxing).

Properties

“I don’t quite understand why I need _= instead of just =” – if you
look closely you DO need the “=”, it’s just that the name of the
getter is always the same as the name of the property while the name
of the setter is always the name of the property with “_=” appended
to it.

Scala Object

“That being said, I’m not sure why these couldn’t just be formally
defined as class methods; I’m not clear on what is gained by having
these be part of another object.” – One thing that you _could_mention
is that static methods (in Java) can’t be part of an interface (so you
can’t say: if you implement interface X you must have a method called
foo, a method called bar and a static method called baz) but in Scala
the companion object can implement interfaces. You’d still have to
think of an example where this is a worthwhile feature to have tho :)

Scala Generics

“Also note that, like in Java, if a class Child extends a class
Parent, Configuration[Child] is not a subclass of
Configuration[Parent].” – Actually you can define that with variance
notations,like you explain the TypeVariance section, so you should
probably add a reference to it