On Sat, Jan 14, 2023 at 7:34 AM Bram Moolenaar <[email protected]> wrote:
>
>
> Most of the implementation of classes has been done.  Feel free to give
> it a try.  You might run into something that is still a todo item, or a
> bug.  Please report this in a reproducible way.
>

Thanks Bram for adding the support for classes.

>
> This is a good moment to evaluate the current choices.  Although the
> syntax and semantics are similar to popular languages, there are also
> some differences.  Hopefully they are easy to understand.
>
> One thing that I had to make a choice for is how to deal with limiting
> access, especially to object members.  Different languages have
> different ways of doing this.  And very different granularity,
> especially when it comes to access by parent or child classes.
>
> Currently I decided to keep it relatively simple and only provide three
> ways:
>
> - public: read and write access, using the "public" keyword
> - default: read access only, no keyword used
> - private: name prefixed with an underscore
>
> Within the inheritance tree there are no limits, a child class can
> access all members of a parent class and vice versa.  There is no
> "protected".
>
> Making the read-only access the default has two reasons.
>
> First of all, it is the most useful and recommended way to declare
> object members.  It avoids having to define "getters" while disallowing
> anybody changing the values.
>
> Secondly, using "public" and "private" keywords is very common, but
> there is no widely used keyword for read-only.
>
> One thing could still be changed: Instead of using the underscore prefix
> to indicate "private" we could use the "private" keyword.  Both are used
> by popular languages.  Although using "private" is more common, more
> recently developed languages use the underscore prefix.  Thus I would say
> both are acceptable choices.
>
>         # currently:
>         this._member
>
>         # alternatively:
>         private this.member
>
> The main advantage of using the underscore prefix is that the "private"
> property can also be seen where the member is used.  The main
> disadvantage is that it's a bit obscure for those users who haven't seen
> this syntax used this way before.
>

I prefer the first approach as it is much easier to spot the private variables
in the code.

Regards,
Yegappan

> Opinions?
>

-- 
-- 
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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/CAAW7x7m13p3JTGyJk-Bk0GtqY6paUR8U%2Bz4mv6%2BgqAyqaUsLbg%40mail.gmail.com.

Raspunde prin e-mail lui