Support for Private class/object methods

[Yegappan Lakshmanan]

Hi all,

The following item is in the todo.txt file for implementing private
methods in a class:

- Private methods?
either: private def Func()
or: def _Func()
Perhaps use "private" keyword instead of "_" prefix?

Function and method names always start with an uppercase letter. So
if we use the
"_" prefix for a private method name then it will diverge from that. So I have
implemented this using the "private" keyword.

Any opinions?

Thanks,
Yegappan

[Ernie Rael]

On 23/08/24 8:18 PM, Yegappan Lakshmanan wrote:
> Hi all,
>
> The following item is in the todo.txt file for implementing private
> methods in a class:
>
> - Private methods?
> either: private def Func()
> or: def _Func()
> Perhaps use "private" keyword instead of "_" prefix?
>
> Function and method names always start with an uppercase letter. So
> if we use the
> "_" prefix for a private method name then it will diverge from that.

That's mostly a parsing issue? The requirement becomes _[A-Z] means private.

> So I have
> implemented this using the "private" keyword.

Can "private" be used with members, in addition to prefixing "_"?
> Any opinions?
I'm personally OK with "private", and happy to avoid the parsing
hassles. Would like to see it usable with class/instance members.

-ernie

>
> Thanks,
> Yegappan
>

[Doug Kearns]

Thanks very much for keeping the ball rolling on this.

For others, there was some previous discussion[1] about it on the list when Bram asked for opinions.  My recollection is that both you and he were in favour of the "_" prefix for call-site identification purposes?

My personal preference would be for the modifier keyword with a symmetric, even if possibly redundant, "public".  I think this is justifiable on the grounds of it meeting the "less weird" requirement for Vim9 script.  While I'm sure there are others, JavaScript is the only language I can think of off the top of my head that defaults to public and uses a sigil for private access.

Thanks again,

Doug

1.  https://groups.google.com/g/vim_dev/c/yYpFNUHdRho/m/xjgrKqMoBQAJ?pli=1

 

[Yegappan Lakshmanan]

Hi,

On Thu, Aug 24, 2023 at 8:50 PM Ernie Rael <err...@raelity.com> wrote:
>
> On 23/08/24 8:18 PM, Yegappan Lakshmanan wrote:
> > Hi all,
> >
> > The following item is in the todo.txt file for implementing private
> > methods in a class:
> >
> > - Private methods?
> > either: private def Func()
> > or: def _Func()
> > Perhaps use "private" keyword instead of "_" prefix?
> >
> > Function and method names always start with an uppercase letter. So
> > if we use the
> > "_" prefix for a private method name then it will diverge from that.
>
> That's mostly a parsing issue? The requirement becomes _[A-Z] means private.
>

Yes. It is a parsing issue. Using the "_" prefix for both private members
and methods will make it symmetric though.

>
> > So I have
> > implemented this using the "private" keyword.
>
> Can "private" be used with members, in addition to prefixing "_"?
>

We can make changes to support the "private" keyword for members also.

>
> > Any opinions?
> I'm personally OK with "private", and happy to avoid the parsing
> hassles. Would like to see it usable with class/instance members.
>

Let me see whether we can support using the "_" prefix for private methods.

Thanks,
Yegappan

[Yegappan Lakshmanan]

Hi,

On Thu, Aug 24, 2023 at 9:11 PM Doug Kearns <dougk...@gmail.com> wrote:
>
> On Fri, 25 Aug 2023 at 13:18, Yegappan Lakshmanan <yega...@gmail.com> wrote:
>>
>> Hi all,
>>
>> The following item is in the todo.txt file for implementing private
>> methods in a class:
>>
>> - Private methods?
>> either: private def Func()
>> or: def _Func()
>> Perhaps use "private" keyword instead of "_" prefix?
>>
>> Function and method names always start with an uppercase letter. So
>> if we use the
>> "_" prefix for a private method name then it will diverge from that. So I have
>> implemented this using the "private" keyword.
>>
>> Any opinions?
>
>
> Thanks very much for keeping the ball rolling on this.
>
> For others, there was some previous discussion[1] about it on the list when Bram asked for opinions.
> My recollection is that both you and he were in favour of the "_" prefix for call-site identification purposes?
>

Yes.

>
> My personal preference would be for the modifier keyword with a symmetric, even if possibly redundant, "public".
> I think this is justifiable on the grounds of it meeting the "less weird" requirement for Vim9 script.
> While I'm sure there are others, JavaScript is the only language I can think of off the top of my head
> that defaults to public and uses a sigil for private access.
>

Thanks for forwarding the email thread. I totally forgot about that
discussion. It is unfortunate
there was no conclusion at the end of that thread that we can refer to.

Regards,
Yegappan

[Ernie Rael]

On 23/08/24 9:10 PM, Doug Kearns wrote:

On Fri, 25 Aug 2023 at 13:18, Yegappan Lakshmanan <yega...@gmail.com> wrote:

Hi all,

The following item is in the todo.txt file for implementing private
methods in a class:

 - Private methods?
        either: private def Func()
            or: def _Func()
    Perhaps use "private" keyword instead of "_" prefix?

Function and method names always start with an uppercase letter.  So
if we use the
"_" prefix for a private method name then it will diverge from that. So I have
implemented this using the "private" keyword.

Any opinions?

Thanks very much for keeping the ball rolling on this.

For others, there was some previous discussion[1] about it on the list when Bram asked for opinions.  My recollection is that both you and he were in favour of the "_" prefix for call-site identification purposes?

My personal preference would be for the modifier keyword with a symmetric, even if possibly redundant, "public". 

Is it only redundant, or is there some semantic meaning or change? Referring only to functions?

About that "_". Looking through that old thread, and thinking about the code I've got. It is convenient to look at a member name and immediately know it's private. Allowing "private" doesn't seem that important; I don't particularly buy into the "only have one way to do it" but private member seems low priority to me.

-ernie

I think this is justifiable on the grounds of it meeting the "less weird" requirement for Vim9 script.  While I'm sure there are others, JavaScript is the only language I can think of off the top of my head that defaults to public and uses a sigil for private access.

Thanks again,

Doug

1.  https://groups.google.com/g/vim_dev/c/yYpFNUHdRho/m/xjgrKqMoBQAJ?pli=1

 

--
--
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/CAJ1uvoBnoV9pM47k%2BGsSDApk3Xciu4RgGrSQJKbc0V1e8NAJjw%40mail.gmail.com.

[shane.qian]

what's the time that 'todo' item added?
2022/02/08 bram had comment about that:
https://github.com/vim/vim/issues/9713#issuecomment-1031938822

--
shane.xb.qian

[Ernie Rael]

Note that the 'todo' item is about class methods, not functions in
general. The discussion where Bram brought up the question is January of
2023.

-ernie

>

[bfrg]

If "public" is omitted, shouldn't class members and method be private by default just like "def" functions and script variables are script-local by default unless prefixed with "export"?

In general, I would also like it to be symmetric. So, either introducing "public" and "private" together, or no modifier keyword at all. In the latter case an underscore indicates private class members and methods whereas public ones don't have an underscore.

And another issue: why isn't this thread shown in GitHub Discussions? Wasn't the whole point of enabling Discussions so that more people can participate in such decision making?

[Ernie Rael]

On 23/08/25 2:07 PM, bfrg wrote:

If "public" is omitted, shouldn't class members and method be private by default just like "def" functions and script variables are script-local by default unless prefixed with "export"?

In general, I would also like it to be symmetric. So, either introducing "public" and "private" together, or no modifier keyword at all.

Any opinion/comment on "read-only" access in favor of adding Getters?

Would "export" be better than "public" in class definitions?

In the latter case an underscore indicates private class members and methods whereas public ones don't have an underscore.

And another issue: why isn't this thread shown in GitHub Discussions? Wasn't the whole point of enabling Discussions so that more people can participate in such decision making?

On Friday, August 25, 2023 at 6:11:34 AM UTC+2 Doug Kearns wrote:

On Fri, 25 Aug 2023 at 13:18, Yegappan Lakshmanan <yega...@gmail.com> wrote:

Hi all,

The following item is in the todo.txt file for implementing private
methods in a class:

 - Private methods?
        either: private def Func()
            or: def _Func()
    Perhaps use "private" keyword instead of "_" prefix?

Function and method names always start with an uppercase letter.  So
if we use the
"_" prefix for a private method name then it will diverge from that. So I have
implemented this using the "private" keyword.

Any opinions?

Thanks very much for keeping the ball rolling on this.

For others, there was some previous discussion[1] about it on the list when Bram asked for opinions.  My recollection is that both you and he were in favour of the "_" prefix for call-site identification purposes?

My personal preference would be for the modifier keyword with a symmetric, even if possibly redundant, "public".  I think this is justifiable on the grounds of it meeting the "less weird" requirement for Vim9 script.  While I'm sure there are others, JavaScript is the only language I can think of off the top of my head that defaults to public and uses a sigil for private access.

Thanks again,

Doug

1.  https://groups.google.com/g/vim_dev/c/yYpFNUHdRho/m/xjgrKqMoBQAJ?pli=1

 

--

--
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/394f9be0-0aef-4c32-9da0-a90ac499723fn%40googlegroups.com.

[Yegappan Lakshmanan]

Hi,

On Fri, Aug 25, 2023 at 2:07 PM bfrg <bfr...@gmail.com> wrote:
>
> If "public" is omitted, shouldn't class members and method be private by default just like "def" functions
> and script variables are script-local by default unless prefixed with "export"?
>

Currently object/class methods are always public and the object/class
private methods
are not supported.

If "public" is omitted, then object/class member variables are
read-only. With "public",
the member variables are read/write. If the member variable name starts with an
underscore, then it is private.

>
> In general, I would also like it to be symmetric. So, either introducing "public" and "private" together,
> or no modifier keyword at all. In the latter case an underscore indicates private class members and
> methods whereas public ones don't have an underscore.
>

I prefer using the underscore character to differentiate between
public and private methods.
I will create a PR to add support for private object/class methods.

>
> And another issue: why isn't this thread shown in GitHub Discussions? Wasn't the whole point of enabling
> Discussions so that more people can participate in such decision making?
>

I am used to sending emails to the mailing list. So I started this
email thread.
We can use Github discussions going forward for other features.

Regards,
Yegappan

[Yegappan Lakshmanan]

On Fri, Aug 25, 2023 at 3:50 PM Ernie Rael <err...@raelity.com> wrote:
>
> On 23/08/25 2:07 PM, bfrg wrote:
>
> If "public" is omitted, shouldn't class members and method be private by default just like "def" functions and script variables are script-local by default unless prefixed with "export"?
>
> In general, I would also like it to be symmetric. So, either introducing "public" and "private" together, or no modifier keyword at all.
>
> Any opinion/comment on "read-only" access in favor of adding Getters?
>
> Would "export" be better than "public" in class definitions?
>

The keyword "export" is already used to export items from one script to another.
So using it to make methods public within a script will be confusing.

Regards,
Yegappan

[shane.qian]

> > If "public" is omitted, shouldn't class members and method be private by default just like "def" functions
> > and script variables are script-local by default unless prefixed with "export"?
> >
>
> Currently object/class methods are always public and the object/class
> private methods
> are not supported.
>
> If "public" is omitted, then object/class member variables are
> read-only. With "public",
> the member variables are read/write. If the member variable name starts with an
> underscore, then it is private.
>
> >
> > In general, I would also like it to be symmetric. So, either introducing "public" and "private" together,
> > or no modifier keyword at all. In the latter case an underscore indicates private class members and
> > methods whereas public ones don't have an underscore.
> >
>
> I prefer using the underscore character to differentiate between
> public and private methods.
> I will create a PR to add support for private object/class methods.
>

i wish you can re-consider, keyword `private` with existed `export/public/static` looks more natural.
// i had pointed out this in another thread mail, but i'd like to say again :-)

> >
> > And another issue: why isn't this thread shown in GitHub Discussions? Wasn't the whole point of enabling
> > Discussions so that more people can participate in such decision making?
> >
>
> I am used to sending emails to the mailing list. So I started this
> email thread.
> We can use Github discussions going forward for other features.
>

i think it's OK (in vim_dev mailing list), basicly this a dev or design related things, may not require wild discussion.

--
shane.xb.qian

[shane.qian]

Or actually i am curious who would use vim9 script to write complex OOP script?
who would really use interface/abstract/class with using all those keyword -_-#
perhaps basic class support was good enough, so far i cannot image who would do

--
shane.xb.qian

[Doug Kearns]

On Fri, 25 Aug 2023 at 15:21, Ernie Rael <err...@raelity.com> wrote:

On 23/08/24 9:10 PM, Doug Kearns wrote:

On Fri, 25 Aug 2023 at 13:18, Yegappan Lakshmanan <yega...@gmail.com> wrote:

Hi all,

The following item is in the todo.txt file for implementing private
methods in a class:

 - Private methods?
        either: private def Func()
            or: def _Func()
    Perhaps use "private" keyword instead of "_" prefix?

Function and method names always start with an uppercase letter.  So
if we use the
"_" prefix for a private method name then it will diverge from that. So I have
implemented this using the "private" keyword.

Any opinions?

Thanks very much for keeping the ball rolling on this.

For others, there was some previous discussion[1] about it on the list when Bram asked for opinions.  My recollection is that both you and he were in favour of the "_" prefix for call-site identification purposes?

My personal preference would be for the modifier keyword with a symmetric, even if possibly redundant, "public". 

Is it only redundant, or is there some semantic meaning or change? Referring only to functions?

It's redundant if there's no 'readonly' access.  It's common for languages to include an access modifier keyword for the default case so I'd prefer there was a modifier keyword for 'readonly' as well if that's the default.

However, I'd be inclined not to offer a default.  I don't find declaration keywords to be a burden.

Regards,

Doug