Disable definition of methods outside of class body

[Night-walker]

I really see no point in supporting C++-like definitions of methods outside of the body of their class. We don't have headers, so the most probable gain from this feature is extra verbosity and chaos in code. I believe it should be disabled, together with the ability to declare non-interface methods without body.

[dumblob]

Well, then we would need to enhance Dao parser to be able to work with unbound symbols (there are cases which need forward declaration - e.g. recursion). This would be imho a significant change and I doubt we would gain some advantages out of it (considering solely the VM).

It's true, that it "inspires" programmers to write chaotic code, but on the other hand it also provides means to make the code better structured and readable. In my opinion it's simply a double-edged sword.

[Night-walker]

Well, then we would need to enhance Dao parser to be able to work with unbound symbols (there are cases which need forward declaration - e.g. recursion). This would be imho a significant change and I doubt we would gain some advantages out of it (considering solely the VM).

What "unbound symbols"? Forward declaration is not needed for contents of a class. Are we discussing the same thing?

It's true, that it "inspires" programmers to write chaotic code, but on the other hand it also provides means to make the code better structured and readable.

I am rather sceptical about better structure and readability. After all, there are interfaces in Dao which can be used for similar purpose -- without the need to search for chunks of class definition all over the code.

[daokoder]

I think avoiding method definition outside of class body may be less convenient sometimes, when a class is big and its methods are long. In such cases, the class body will be exceedingly long, and some blocks are nested in exceedingly deep levels. Also, placing method declarations together may be better for readability, since one can see at a glance what a class can do with what methods.

Of course, allowing implementation of class methods at arbitrary locations is clearly a bad idea, so I prefer to go with a compromised solution, which is, methods implementation must be in the same file as the class definition. (The restriction could be further strengthened by not allowing definition of any other classes, but this may just provide very limited benefit.) This is already done, BTW.

[Night-walker]

OK, I see your point. To address the clarity issue, it is indeed sufficient to restrict the use of external method definitions to the file where the corresponding class resides.

But there still is a case when some method is left not implemented. For non-interface methods, it is preferable to raise compile-time error in this case. That would be better than a runtime failure.

[daokoder]

But there still is a case when some method is left not implemented. For non-interface methods, it is preferable to raise compile-time error in this case. That would be better than a runtime failure.

Right, this can be done. I haven't considered this, thanks for pointing it out.

[dumblob]

What "unbound symbols"? Forward declaration is not needed for contents of a class. Are we discussing the same thing?

Yes we are. I mistakenly put the class prefix in front of the routines:

class C {
  static routine C::r(i: int) => int { return (i < 10) ? r2(i) : i }
  static routine C::r2(i: int) => int { return r(i +1) }
}
io.writeln(C::r2(5))

and obviously obtained:

0$ dao test.dao 
[[ERROR]] in file "/home/test/test.dao":
  At line 1 : Invalid class definition --- " class C { static routine C::r(i ... ";
  At line 2 : Invalid function definition --- " routine C::r(i: int) => int { return ... ";
  At line 2 : Method not declared --- " r ";
1$

But without the C:: prefix, there is no issue.

Anyway, I like the solution of restricting the use of external method definitions to the file where the corresponding class resides and checking if all methods are implemented.