One more thing about vim9 class: can we define a named or anonymous class inside a function ? That can be used to simulate a closure,
And maybe, someday, we can translate javascript or lua to vim9script with this feature. 在2022年12月28日星期三 UTC+8 00:29:24<Bram Moolenaar> 写道： > > > > > This following currently defines a field and is, without context, > > > > indistinguishable from any other assignment. Is that intended? > > > > > > With "var" it's indistinguishable from another declaration, I don't > > > think it matters much that it looks like an assignment otherwise. > > > > > > > There's only one declaration per class assuming either a qualified name > is > > used in the declaration or normal shadowing rules apply. > > > > So, ignoring subjective aesthetic issues, this would allow for tooling to > > more easily identify the declaration. > > Yes, there are some reasons to declare object members with "var". > It's hard to decide what matters most. Perhaps "making it look like a > declaration" is more important than other reasons. The space taken up > by the extra "var" keyword probably doesn't matter much. > > > > > It seems from the documentation that static fields can be referenced > as > > > > bare identifiers? This feels a bit unexpected to me given that > instance > > > > fields are always qualified. > > > > > > Static fields (class members) are totally different from object > members. > > > I have always found it confusing, in many languages it's hard to tell > > > them apart, especially if the declaration is further away. Always using > > > "this" for object members helps a lot for this. I would not know what > > > to use for class members. The only thing I have seen is using the class > > > name, which can be long (and gets tricky when using inheritance). > > > I believe most languages access class members directly, without a > > > prefix. > > > > I think they're much the same in terms of the problems the required > "this" > > qualifier is attempting to address. Static fields also need > disambiguation > > in shadowed contexts and could, arguably, also use better identification. > > Assigning to a static class member in a constructor is unusual, thus the > common problem that an argument name matches a member name is unlikely > to happen for a class member. We could probably disallow shadowing a > class member. We can at least start with that and see if that doesn't > cause annoyance. > > > Are methods going to need to be qualified too? > > Object methods are always called on an object "obj.method()". > I suppose "this.method()" also works (don't see this very often). > Just using "method()" probably needs to be disallowed. Especially if we > require prefixing "this." for object members. > > > Cards on the table, I'm not in favour of requiring qualified > > references. I just found it surprising that only unqualified instance > > fields were considered a problem. > > That is the reality. All this is much more about what a developer > encounters on a regular basis than theory or philosophy. Especially > when it comes to what mistakes people tend to make and whether it's > possible to give a helpful error for them. Every time I have started > using a new language (usually advertised as being the best ever) I have > run into things that don't work well in practice. > > -- > ARTHUR: Charge! > [They all charge with swords drawn towards the RABBIT. A tremendous twenty > second fight with Peckinpahish shots and borrowing heavily also on the > Kung Fu and karate-type films ensues, in which some four KNIGHTS are > comprehensively killed.] > ARTHUR: Run away! Run away! > "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD > > /// Bram Moolenaar -- br...@moolenaar.net -- http://www.Moolenaar.net \\\ > /// \\\ > \\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ /// > \\\ help me help AIDS victims -- http://ICCF-Holland.org /// > -- -- 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/a650df7d-f737-453d-b774-ba36263a3dfen%40googlegroups.com.
