Constructor arguments are visible in entire class -- a feature or a bug?

Question

Consider such code (this is just example not real code):

class Foo(url : String) extends Bar(url)
{
  def say() { println(url) }
}

It compiles and it works. With nonsense results "of course". I am too newbie to judge, but for me it serves no purpose but confusion -- by definition it is impossible that the argument of the constructor could be reachable directly in another method.

Could someone more experience in Scala could point out condition when it might work or make sense? Or confirm my suspicion this is flaw in current Scala compiler.

Update

class Bar(val Url : String)
{
}

Why "nonsense". Because my will (no "var" and no "val" in Foo) was to just pass the argument, nothing else. So when I actually use the constructor argument it is just matter of what entity I use by mistake. When you write on purpose, you hit the jackpot each time, but if you don't (i.e. you make a mistake in spelling), you use entities by random. It is not the code does not make sense, it is the computation just does not make sense, I could roll a dice as well. There is a method scope, and I don't see a reason why there shouldn't be constructor scope.

Update -- workaround

So it seems this evil construct is really part of the language (by design). As UserUnknown and Tomasz Nurkiewicz suggested the only line of defense against making stupid typo is convention, however lower-upper case is not good. "A" and "a" differ a lot, but "U" and "u" not much. Introducing one special character (as Tomasz showed) is much better, because it is possible to visually detect fishy usage of constructor argument.

I will use "$" for "just-passing" constructor arguments, it is harder to type for me, and you don't see this character too often in the code.

Thank you for the answers!

Why it is evil? Because implicit actions should be allowed explicitly by users -- good examples are "dynamic" in C#, implicit conversions in Scala. And examples of breaking this rule which led to tons of problems are -- implicit conversions to bool in C++, implicit constructors in C++, declaration by usage in Perl. And this particular case is very, very close to the mentioned perlism, in Perl finally there was change in interpreter to detect such misusages, why Scala repeated the same mistake? I wonder.

Answer 1

Your suspicions are entirely merit-less. This is by design.

Parameters of a class are part of the class. They'll be preserved as field if necessary (such as in your example), or not if they are never used outside construction.

So, basically, if you don't need it as a field, it won't be. If you do, it will. And you'll never write a single extra character of code to tell the compiler what it can figure out by itself.

Answer 2

It's not a bug, it's a feature. In fact, a really nice one. Need an example how useful it is? Here is how I use it with Spring and dependency injection via constructor:

@Service
class Foo @Autowired() (bar: Bar, jdbcOperations: JdbcOperations) {

    def serverTime() = bar.format(jdbcOperations.queryForObject("SELECT now()", classOf[Date]))

}

Equivalent code in Java:

@Service
public class Foo
{
    private final Bar bar;
    private final JdbcOperations jdbcOperations;

    @Autowired
    public Foo(Bar bar, JdbcOperations jdbcOperations)
    {
        this.bar = bar;
        this.jdbcOperations = jdbcOperations;
    }

    public String serverTime()
    {
        return this.bar.format(this.jdbcOperations.queryForObject("SELECT now()", Date.class));
    }

}

Still not convinced?

Short tutorial:

class Foo(var x: Int, val y: Int, z: Int) {
  println(z)
  //def zz = z
}

x will become a variable with getters and setter. y will become an immutable variable and z will become an immutable variable only if zz method is uncommented. Otherwise it will remain a constructor argument. Neat!

UPDATE: I see your point now! The following code works as expected by accessing url variable in base class:

class Bar(val url)

class Foo(_url : String) extends Bar(_url)
{
  def say() { println(url) }
}

I agree, this is both ugly and is asking for trouble. In fact I once hit this problem myself when using Scala classes as Hibernate entities - I used constructor parameter instead of field in base class which caused duplicated field to be created: one in base class and one in derived class. I wouldn't even notice but Hibernate was screaming at runtime that duplicated column mapping was defined.

So I have to somewhat agree with you - this is somehow confusing and might be error-prone. This is the price you pay for "implicitness" and concise code.

However note that no modified and val modifier before constructor argument are different. Without modified immutable field is created, while val additionally adds getter.

Answer 3

Scala creates a field from a constructor parameter when such an parameter is referenced by a method in the class. I'm having trouble finding fault with the way that this works.

For the simple case everything works as expected:

scala> class Bar(val url: String)
defined class Bar

scala> class Foo(url: String) extends Bar(url) {
     | def say() { println(url) }
     | }
defined class Foo

scala> new Foo("urlvalue").say
urlvalue

If we introduce some confusion over the case of the constructor parameter this example still works as expected:

scala> class Bar(val Url: String)
defined class Bar

scala> class Foo(url: String) extends Bar(url) {
     | def say() { println(url) }
     | }
defined class Foo

scala> new Foo("urlvalue").say
urlvalue

Interestingly you might think that this has worked because it has introduced a lower-case url field in Foo in addition to the upper case Url in Bar, but that doesn't seem to be the case - the compiler seems to be smart enough to know that it can go to Url to get the value of url in say, as no lower case field is generated.

scala> :javap -private Bar
Compiled from "<console>"
public class Bar extends java.lang.Object implements scala.ScalaObject{
    private final java.lang.String Url;
    public java.lang.String Url();
    public Bar(java.lang.String);
}

scala> :javap -private Foo
Compiled from "<console>"
public class Foo extends Bar implements scala.ScalaObject{
    public void say();
    public Foo(java.lang.String);
}

The only time I can see that this gets confusing is if you mis-spell a var field. In this case you do actually introduce a new field, and the two can get out of step.

scala> class Bar(var Url: String)
defined class Bar

scala> class Foo(url: String) extends Bar(url) {
     | def say() { println(url) }
     | }
defined class Foo

scala> val f = new Foo("urlvalue")
f: Foo = Foo@64fb7efa

scala> f.say
urlvalue

scala> f.Url = "newvalue"
f.Url: String = newvalue

scala> f.say
urlvalue

scala> :javap -private Foo
Compiled from "<console>"
public class Foo extends Bar implements scala.ScalaObject{
    private final java.lang.String url;
    public void say();
    public Foo(java.lang.String);
}