Replies: 5 comments
-
I think the vim9script spec for vim9.1 can now support backwards compatibility. Large projects, using OOP features, can be written to the current vim9.1 spec and continue to work in future releases. And by limiting vim9.1 features, there's maximum flexibility for future language development. I think there's agreement on the current spec; but, without changing the spec, the document could use some additional info, clarifications, and/or fixes. And the implementation requires some targeted work, for example error checking to insure a type can not be used as a class (a TODO item, see below). Spec and doc updates and examples The most recent spec changes/additions would benefit from improved documentation.
Implementation Now with
can be completed by giving an error, also obviates #12961. See reference [1]. Conundrums There are difficulties created because some language features are actually implemented as builtin functions. In particular, Builtin functions tend to be careful about checking types; but then you get a myriad of function specific error messages when passing a type. The An additional problem is that some builtins (
The commit "Modify instanceof() to handle varargs of classes instead of list", in [1], is an example of dealing with (2). For [1] "Prevent class name assign" yegappan#2 Addendums in order |
Beta Was this translation helpful? Give feedback.
-
I sincerely hope not. There's lots of open questions in discussion, issue, and PR comment threads. |
Beta Was this translation helpful? Give feedback.
-
I think I've seen most of the recent comments about issues. I neglected to copy links to them from this issue. Oops. There's stuff that is not liked by some or that could be done differently, I've been guided by the last "official" statement on the vim9script requirements for vim9.1.
with the caveat about leaving stuff out that might hinder future development. |
Beta Was this translation helpful? Give feedback.
-
Addendum-1 to #13454 (comment) The following additional possibilities for dealing with the Conundrums have come up recently.
(2) is probably the best assuming One of the features of the current scheme is that a list of classes can be built prgrammatically; but is this important. Is it OK to require that the classes to be hardcoded as shown in the following
It might be more of an issue with |
Beta Was this translation helpful? Give feedback.
-
I think the time has come... |
Beta Was this translation helpful? Give feedback.
-
Around the end of August, in the thread "Updates on the Vim project", it was suggested that vim9script needed "one more week and then stop". The primary goal was "make sure that all the Vim9 class changes that may break backward compatibility go in before the Vim 9.1 release". It turned out that vim9script was not as well specified or fully implemented as people thought; of necessity, the time frame got pushed out. In addition a lot of the TODO list was completed.
Can the spec be frozen for vim9.1?
This discussion is for comments and consideration on whether or not vim9.1's vim9script is ready for release.
Beta Was this translation helpful? Give feedback.
All reactions