Language Specification: Default constructor is a foot gun

[dkearns]

The default constructor's parameter list order matches that of the field declarations. This seems like a probable cause of surprising bugs for casual users. I don't really think the feature pulls its weight.

Generally languages with this relationship between constructor parameters and fields use the constructor's parameter list to automagically declare fields. In Vim9 script the relationship is inverted.

E.g., switching the declaration order of the fields below causes Subtract() to produces a different result without error. There's an obviously natural ordering of fields here but this not always the case.

class A
  this._x: number
  this._y: number
  def Subtract(): number
    return this._x - this._y
  enddef
endclass

echomsg A.new(1, 2).Sub()

Field declaration order essentially becomes part of the class 'interface'.

The best solution is to support named parameters and given the languages purported interest in call-site annotations this would be generally useful.

The obvious workaround is to declare explicit constructors.

I noted this issue when there was an initial request for comments but still managed to stumble over it.

[errael]

In todo.txt

  - add to help: when using a default new() method then reordering object
    members may cause trouble.  Can define new() without arguments to avoid.

I've gotten into the habit of putting

def new()
enddef

in all classes.

[dkearns]

Can define new() without arguments to avoid.

I don't understand what this achieves other than requiring a second named constructor with parameters.

I've gotten into the habit of putting ... in all classes.

You mean as a discipline to remind you to implement it? I fear I'm missing something here.

[errael]

what this achieves

By defining an empty new() to start with, there's no default constructor, no unexpected consequences of changing the order of variable declarations. If I use a constructor that I intend to have, I get an error and can then change the empty constructor to what's needed.

As you said

obvious workaround is to declare explicit constructors

Yep, starting with an empty new() forces that.

[dkearns]

Thanks. No magic then. :)

[errael]

BTW, for small things I find the default constructor handy. Of course, somethings things don't remain small, so ...

[dkearns]

Using a "primary constructor" approach might be an improvement. It's explicit.

class A(this._x: number, this._y: number)
  this._z: number
  def newWithZ(this._x, this._y, this._z)
  enddef
endclass

A.new(1, 2)
A.newWithZ(1, 2, 3)

[dkearns]

• add to help: when using a default new() method then reordering object members may cause trouble. Can define new() without arguments to avoid.

The fact that it needs to be documented with a warning seems reason enough to remove the feature. Is this "trouble" balanced by any purported convenience?

I'm not convinced the generated constructor is even applicable in the most general case. It seems most suitable for classes acting as records.

I think the easiest solution is to drop the feature and default to a nullary constructor. Other arguably better solutions include a primary constructor or named parameters. I note that Zimbu uses a simple nullary constructor..

Overall, I find this feature a bit gimmicky and counter to the aim of being "closer to commonly used programming languages".

@yegappan if you're not interested in changing this can you please just close it?

[yegappan]

If we replace the default autogenerated new() constructor which accepts all the member variables as arguments with an empty (or null) constructor, then to initialize the object variables to an initial value, the user needs to create a constructor method which will essentially be the same as the default constructor. For example, consider the following example (using the default constructor):

vim9script
class A
    this.n: number
    this.s: string
endclass

var a = A.new(100, 'abc')

This creates an object and initializes "n" to 100 and "s" to "abc" using the default constructor.

If we remove the default constructor, then the user needs to use the following to do the same:

vim9script
class A
    this.n: number
    this.s: string

    def new(this.n, this.s)
    enddef
endclass

var a = A.new(100, 'abc')

As you can see the user needs to now manually add the previously auto-generated default constructor.

Bram added the autogenerated default constructor to simplify this. But this suffers from the side-effect
that if the order of the member variables is changed, then the constructor method arguments also change.

Does using a generated default constructor method to initialize the object variables bring more value than
asking the user to manually add the constructor to initialize the variables?

[chrisbra]

I agree and I don't like the requirement of requiring the user having to write default constructors and I think the case that one is re-ordering arguments is happening far less often.

[errael]

the case that one is re-ordering arguments is happening far less often.

Lucky you.

I usually mix coding/design; that requires a liberal dose of refactoring to keep things clean. And when it's all done (as far as any software can be done), I like to spend a few days testing and more refactoring to get it in shape so that when I come back to it after months/years I can get up to speed quickly. I can protect myself from the default constructor, but there's other things that cause problems not seen with other languages/environments.

[dkearns]

I agree and I don't like the requirement of requiring the user having to write default constructors and I think the case that one is re-ordering arguments is happening far less often.

The issue isn't a trade-off between the two. In fact, the less frequently one reorders the more likely they are to shoot themselves in the foot, it only takes once. The issue is really how easy it is to become subconsciously reliant on the default constructor and forget about the unusual relationship.

I use the default constructor all the time for toy examples; I've stopped thinking about constructors in that context. It'll take quite a lot of experience to ingrain the fact that reordering field declarations requires updating constructor call sites so as not to make that bone-headed mistake in the wee small hours.

Can anyone name another language that has dependency between field declaration order and an auto-generated function (possibly excluding something generated from annotations)? [Not rhetorical]

I'll close this in a few days if there's no flood of support for removing it.

[errael]

I wrote a response to this, and ended up turning it into enhancement request #13460. The bottom line is:

vim9script wants to be suitable for both simple scripting tasks and large scale projects; conflicting requirements. Over the last months the more I do simple things, the more I like the default constructor. If the default constructor goes away, I'll be disappointed but not heartbroken. As mentioned earlier, in larger projects I always define

def new()
enddef

, unless I forget, to avoid the default constructor.

Instead of pushing the language in one direction or the other, I'd say that vim9script development tools can alleviate a lot of issues associated with the language targeted at both tiny and large projects/tasks.

[dkearns]

Is using a generated default constructor method to initialize the object variables brings more value than
asking the user to manually add the constructor to initialize the variables?

I understand all the issues and trade-offs. I just came to the conclusion that it doesn't bring enough value.

It seems like the sort of feature that will cost some small number of users, particularly inexperienced programmers, ten minutes of head-scratching and a smaller number of users long-lived bugs. It made me think of Wat!.

As mentioned, I think some sort of primary constructor model solves all of these issues. This syntax is reasonably common, particularly in more recently developed languages.

Anyway, I don't want Ernie to be disappointed; it reminds me of my father.

[errael]

some sort of primary constructor model solves all of these issues

I don't understand what this is. Is it magic or something the user needs to create? What happens if members are reordered/added/deleted.

[dkearns]

Something like this, as mentioned earlier:

class A(this._x: number, this._y: number)
  ...
endclass

A.new(1, 2)

Rather than a constructor created from fields, the fields are declared as part of the constructor. The point being that a reordering of the parameter list triggers the same obvious need for call-site changes as a reordering of any function's parameter list.

[yegappan]

If a class has many fields, then the argument list in class A(...) will become too long.

[dkearns]

It'd be the same as a manually defined constructor except for differences in class name vs "new" length (and excluding any extends/implements) It could elide the "this" too. It's shorter in lines as well.

It's used by other languages that I like and haven't considered this a problem. It'd probably require a bit of thought on semantics around the edges though.

I quite like this, in the general case too, so might not be the most objective. :)

[errael]

Something like this, as mentioned earlier:

class A(this._x: number, this._y: number)
  ...

I wasn't sure whether or not that was an example language to express a point.

Oops, still confused

Rather than a constructor created from fields, the fields are declared as part of the constructor

looks like a class definition, not a constructor. Ah, the class defn auto-generates a constructor whether you want it or not.

reordering of the parameter list triggers the same obvious need ...

OK. So your foot is still a target, but it's more obvious that your foot's at risk.

And for a comment that only belongs here tangentially:
I'd rather have commands to

• lint for "using default constructor"
• generate constructor from fields
• refactor: change function/method arguments