> > > 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 -- b...@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/20221227162916.A4C041C0AA3%40moolenaar.net.
