Vim9: Default object member access
Yegappan Lakshmanan
From the email thread
https://groups.google.com/g/vim_dev/c/yYpFNUHdRho/m/xjgrKqMoBQAJ?pli=1
and the following items in the todo.txt file:
- Change access: public by default, private by prefixing "_".
Check for error: can't have the same name twice (ignoring "_" prefix).
This is not yet implemented. We cannot change this after releasing Vim 9.1.
Should we make this change now?
Thanks,
Yegappan
shane qian
Sent: Friday, August 25, 2023 9:50:28 PM
To: vim_dev <vim...@googlegroups.com>
Subject: Vim9: Default object member access
--
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+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CAAW7x7mXbp71Omn3957S-fYFy1zwfbqGY%3D8h5CXqphQUQ%3DST0A%40mail.gmail.com.
Yegappan Lakshmanan
On Fri, Aug 25, 2023 at 9:01 AM shane qian <shane...@live.com> wrote:
>
> the default perhaps was `protect`, since looks default it cannot be accessed out of pkg.
>
> I think another bram's comment in another github issue ticket (I cannot open that google link) had
> showed his preference which is using `private` keyword vs not magic leading underscore.
>
with an underscore and
the keyword "private" is not used. If we use the "private" keyword
for private object methods,
then it will be different from object member variables.
To keep them symmetric, either we should support the "private" keyword
for both the private
member variables and private methods or support the underscore for both of them.
Regards,
Yegappan
shane qian
To: vim...@googlegroups.com <vim...@googlegroups.com>
Subject: Re: Vim9: Default object member access
Ernie Rael
Default read-only is my preference; more precisely not
default public. (Hasn't changed since that thread was
active.) Having worked with vim9class, I don't feel as strongly
about it as I did at the beginning of the year; but considering
how expensive function calls are, having a read-only mechanism is
not only a safety advantage.
Error if both "_foo" and "foo"; strongly think there should be an
error.
The only comment I saw from Bram in the thread specifically about
default public versus read-only has to do with simple
versus safe. From the thread, in response to a suggestion
that public should be the default:
About public/private/read-only: Making the default public is certainly
possible. I think most languages have it that way, even though it's not
a safe choice.
I do like the read-only access. Quite often you want to disallow any
code outside of the class to change a member, so that you can make sure
the value is valid. But making it private means you have add a
"getter" and call it. [...]
Nevertheless, if we give priority to keeping it simple, making members
public by default and using the underscore for private is the way to go.
I was aghast (well, maybe just surprised) to see that
vim9script
class C
this._foo: number
this.foo: number
def Dump()
echo this._foo this.foo
enddef
endclass
C.new(3, 5).Dump()
works. I agree with this comment from the thread about allowing
both "_foo" and "foo"
No, we should not allow that, it is not only confusing, it also makes it
difficult to change a member from private to public later.
-ernie
Thanks, Yegappan
Yegappan Lakshmanan
>
> best choice was leading lowercase, but seems it's not a choice in vim script.
>
> so I prefer and vote both to use leading `private` for var and method.
> and in that github ticket I think bram also said he wish it's `consistent`.
> vs leading underscore was a bit magic, IMO it even may lost in kw search since it needed to ignore leading _ to confirm.
>
apparent that the referred method or member variable is private.
Otherwise one needs to look at the method/variable definition to see whether it
is private or not. I prefer the leading underscore for private methods and
member variables.
shane qian
apparent that the referred method or member variable is private.
--
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+u...@googlegroups.com.
Doug Kearns
Yegappan Lakshmanan
This means that
we cannot change the current accessibility of the object/class members
and methods.
Regards,
Yegappan