On Mon, 23 Jan 2023 at 23:53, Bram Moolenaar <b...@moolenaar.net> wrote:
>
> I expected a lively discussion about alternatives for the class
> implementation, but nothing much happened.
Some of us are old soldiers with too many scars. :)
I'm a bit short on time today but I have a few thoughts, some of which may
be partially reiterated from the previous related thread, to keep the ball
rolling.
= Field and Method Declaration Syntax =
I still find the difference between field and method declaration styles
quite jarring after playing with them for a while. In my experience most
languages reuse their variable and function declaration syntax, with some
additions, for this. TypeScript and JavaScript are exceptions that spring
to mind.
I think it's reasonable, though unnecessary, to introduce new syntax for
member declarations but we're currently only doing so for fields.
So my preference would be to use one of the following.
# Syntax-1
class Foo
this.bar: number = 42
this.Baz(qux: number): number {
return this.bar + qux
}
endclass
# Syntax-2
class Foo
var bar: number = 42
def Baz(qux: number): number
return this.bar + qux
enddef
endclass
I think we could get away with curly braces in the Syntax-1 version as
they're already used for lambda blocks and others.
Using Syntax-2, fields are declared as variables would be in other contexts
and then qualification with "this" could be required to access them. Then,
the only new syntax rule is the qualification requirement. This was also
proposed in the earlier thread by Maxim but didn't seem to garner any
comment.
var this.bar: number = 42 has been proposed but that is also jarring as
declarations of qualified identifiers aren't allowed in any other context
and the qualification is redundant.
Syntax-2 is what I would have guessed the class declaration syntax would
look like after having previously worked with Vim9 script. I think
anything else is an unnecessary complication so it would be my strong
preference.
= Underscore for Private Access =
The current implementation's asymmetry with regard to the private
underscore prefix and public modifier keyword isn't particularly elegant.
I note that it largely disappears with your newly proposed change of
defaulting to public access.
Irrespective, I'd prefer keywords were used for access modification. A
leading underscore is used for many ad-hoc purposes such as reserved words,
member fields, pseudo private fields and generally to work around perceived
deficiencies in a language. It has a lot of baggage and I wouldn't like to
see it become semantically significant.
Dart uses this scheme for library level access but they later introduced a
@protected annotation. Keyword modifiers are more flexible and future
proof.
JavaScript uses the even uglier # sigil but IIRC that was largely done for
JavaScript specific reasons that aren't pertinent.
Leading underscores are also ugly, to my eye, and I'd consider it an
unfortunate addition after the identifier prefix requirements were cleaned
up for Vim 9.
For example, when it's paired with required this qualification we get the
following from the help section on private members:
def GetLnum(): number
if this._lnum > this._lineCount
return this._lineCount
endif
return this._lnum
enddef
rather than the infinitely more readable:
def GetLnum(): number
if lnum > lineCount
return lineCount
endif
return lnum
enddef
The "this" qualification and "_" prefix are both useless to me when reading
or writing this so some of those lines are almost 50% noise. That's a
simple method, I think it can only get worse.
= Miscellaneous =
A few other questions that occurred to me:
- Is it intended that public fields can have the same name (ignoring the
underscore) as private fields?
- Are private methods planned? I don't think I noticed any reference to
these one way or the other in the help.
- Are final fields planned?
Regards,
Doug
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/CAJ1uvoAMZ%3DipT_Fy0gCWUY8yfzm%3DrBMQ8TXPwrLbxB9T3O0BGg%40mail.gmail.com.
