s.txt
>
> The Vim9 class todo list is here:
> https://github.com/vim/vim/blob/master/runtime/doc/todo.txt#L124
Thanks for that. I appreciate your hard work here. Please anybody
interested in using the new Vim9 class implementation test it out and
provide feedback.
Thanks,
Christian
--
Hi all,
The following Vim9 class features have been implemented so far:
1. Class definition and object creation
2. Class variables and methods
3. Object variables and methods
4. Read-only, Read-write and private access control for class/object
variables
5. Extending a class (overriding methods)
> I notice that it's planned to allow classes to "specify" an interface.
> Does this not make interfaces themselves redundant? I can't see any
> utility to them over abstract classes that specify an interface.
An abstract class and an interface have several similarities. Some
languages do not
On Sun, 15 Jan 2023 at 02:34, Bram Moolenaar 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.
>
> This is a good moment to evaluate the
On Fri, Feb 03, 2023 at 12:55:30PM +, Bram Moolenaar wrote:
> > On Thu, Feb 02, 2023 at 05:28:03PM +, Bram Moolenaar wrote:
> > > 3. Add a mechanism to name the members in the call, e.g.
> > > var obj = Class.new(line = 5, column = 0)
> > >This is similar to 2. but puts it in one
On Fri, 3 Feb 2023 at 04:28, Bram Moolenaar wrote:
>
> Doug Kearns wrote:
>
> > I was just looking at the constructor documentation and noticed that the
> > default constructor includes parameters for each field in the order they
> > were declared. Having to change all the constructor call
> On Thu, Feb 02, 2023 at 05:28:03PM +, Bram Moolenaar wrote:
> > 3. Add a mechanism to name the members in the call, e.g.
> > var obj = Class.new(line = 5, column = 0)
> >This is similar to 2. but puts it in one line.
> >It requires marking a method to not use positional
On Thu, Feb 02, 2023 at 05:28:03PM +, Bram Moolenaar wrote:
> 3. Add a mechanism to name the members in the call, e.g.
> var obj = Class.new(line = 5, column = 0)
>This is similar to 2. but puts it in one line.
>It requires marking a method to not use positional arguments.a
>
>
On 23/02/02 9:28 AM, Bram Moolenaar wrote:
Doug Kearns wrote:
I was just looking at the constructor documentation and noticed that the
default constructor includes parameters for each field in the order they
were declared. Having to change all the constructor call sites when
reordering field
Doug Kearns wrote:
> I was just looking at the constructor documentation and noticed that the
> default constructor includes parameters for each field in the order they
> were declared. Having to change all the constructor call sites when
> reordering field declarations seems like a probable
On Sun, 15 Jan 2023 at 02:34, Bram Moolenaar 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.
>
> This is a good moment to evaluate the
On 23/01/24 10:23 AM, Ernie Rael wrote:
On 23/01/23 4:53 AM, Bram Moolenaar wrote:
I expected a lively discussion about alternatives for the class
implementation, but nothing much happened. Does this mean that most
people agree with making this changed:
1. Make object members public
Bram Moolenaar wrote:
> 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
It can be fine, but:
- it's not
On 23/01/23 4:53 AM, Bram Moolenaar wrote:
I expected a lively discussion about alternatives for the class
implementation, but nothing much happened. Does this mean that most
people agree with making this changed:
1. Make object members public by default. They can be read and written
from
Doub Kearns wrote:
> I'm a bit short on time today but I have a few thoughts, some of which may
> be partially reiterated from the previous related thread, to keep the ball
> rolling.
Thanks for your opinions. I'll take them into account.
> = Underscore for Private Access =
>
> The current
On Mon, 23 Jan 2023 at 23:53, Bram Moolenaar wrote:
>
> I expected a lively discussion about alternatives for the class
> implementation, but nothing much happened.
Some of us are old soldiers with too many scars. :)
I'm a bit short on time today but I have a few thoughts, some of
I expected a lively discussion about alternatives for the class
implementation, but nothing much happened. Does this mean that most
people agree with making this changed:
1. Make object members public by default. They can be read and written
from anywhere.
2. The only other possibility
> So, instead of using the "this." prefix, vim9 could specify that member
> variable names must either use the @ prefix for public, or use the _ prefix
> for private. ie., all member variable names must have one of these two
> prefixes. I think this is worth considering, because it's
So, instead of using the "this." prefix, vim9 could specify that member
variable names must either use the @ prefix for public, or use the _ prefix
for private. ie., all member variable names must have one of these two
prefixes. I think this is worth considering, because it's simple,
On Sunday, 15 January 2023 at 03:02:57 UTC+11 yegapp...@gmail.com wrote:
On Sat, Jan 14, 2023 at 7:34 AM Bram Moolenaar wrote:
>
> Currently I decided to keep it relatively simple and only provide three
> ways:
>
> - public: read and write access, using the "public" keyword
> - default:
On Sat, Jan 14, 2023 at 7:34 AM Bram Moolenaar 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
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.
This is a good moment to evaluate the current choices. Although the
syntax and semantics are similar
> - declaring a class inside a function allows me put related code together
> - can be used to simulate a closure function.
>
> example for java:
>
> button.setOnClickListener(new View.OnClickListener() {
> @Override
> public void onClick(View v) {
>
- declaring a class inside a function allows me put related code together
- can be used to simulate a closure function.
example for java:
button.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
AsyncTaskRunner runner = new
> 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,
It can be made possible, but the usefulness might be minimal. Perhaps
you can give an example (possibliy in another language) of what you want
to do.
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 写道：
>
> > > > This following currently
> > > 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.
> >
>
>
On Mon, 26 Dec 2022 at 02:02, Bram Moolenaar wrote:
[...]
> > 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
On Tuesday, 27 December 2022 at 11:14:33 UTC+11 Christopher Plewright wrote:
>
>
> Another possibility occurred to me, that you could keep; *function* and
> *endfunction*
> That could still be used to always mean *static *functions - as that
> essentially does now already - I mean, because
On Monday, 26 December 2022 at 22:59:19 UTC+11 Bram Moolenaar wrote:
> I think that makes it a static class "function", and not a class
> "method".
>
> That depends on how you define this. A method usually implicitily gets
> an extra argument or is aware of its context. It does not
> On 22/12/25 1:07 PM, Bram Moolenaar wrote:
> >> With 9.0.1094, in the script that follows, attempting to read a
> >> classMember through an instance fails;
> >>
> >> echomsg c.classMember
> >>
> >> should it?
> > No, an object does not provide a class member.
> >
> >> I suppose requiring
> > I don't think it's a good idea to access static class function from
> > an object instance of that class. Also, I would not name that
> > function with "Member" if it is a static function, because member
> > implies that it is a member method of an object instance. I think
> > that could
On Monday, 26 December 2022 at 10:26:50 UTC+11 err...@raelity.com wrote:
> On 22/12/25 2:54 PM, Christopher Plewright wrote:
>
> I didn't know it was documented that there could be a static class
> function. The whole point of the question was to determine if there could
> be a static class
>
>
> > I thought that the declaration would be like this;
> >
> > this.name : *string *= "Somebody"
> >
> > Or is auto-type detection at play here too?
>
> It's called type inference. The type of the expression is used as the
> type of the variable. In most cases this works very well,
On 22/12/25 2:54 PM, Christopher Plewright wrote:
On Monday, 26 December 2022 at 09:08:22 UTC+11 err...@raelity.com wrote:
On 22/12/25 1:07 PM, Bram Moolenaar wrote:
With 9.0.1094, in the script that follows, attempting to read a
classMember through an instance fails;
On Monday, 26 December 2022 at 09:08:22 UTC+11 err...@raelity.com wrote:
> On 22/12/25 1:07 PM, Bram Moolenaar wrote:
>
> With 9.0.1094, in the script that follows, attempting to read a
> classMember through an instance fails;
>
> echomsg c.classMember
>
> should it?
>
> No, an object does
On 22/12/25 1:07 PM, Bram Moolenaar wrote:
With 9.0.1094, in the script that follows, attempting to read a
classMember through an instance fails;
echomsg c.classMember
should it?
No, an object does not provide a class member.
I suppose requiring the class name makes it most clear, but
> With 9.0.1094, in the script that follows, attempting to read a
> classMember through an instance fails;
>
> echomsg c.classMember
>
> should it?
No, an object does not provide a class member.
> I suppose requiring the class name makes it most clear, but I recall
> mention that
With 9.0.1094, in the script that follows, attempting to read a
classMember through an instance fails;
echomsg c.classMember
should it? I suppose requiring the class name makes it most clear, but I
recall
mention that classnames can get long. I suppose a getter could be added.
Can a
> On Sunday, 25 December 2022 at 02:34:35 UTC+11 Doug Kearns wrote:
>
> > On Mon, 19 Dec 2022 at 00:33, Bram Moolenaar wrote:
> >
> >>
> >> One thing I'm not yet sure about is the declaration. Currently it works
> >> like this:
> >>
> >> this.name: string
> >> this.gender:
> > One thing I'm not yet sure about is the declaration. Currently it works
> > like this:
> >
> > this.name: string
> > this.gender: Gender
> >
> > Notice that there is no "var" keyword. It's not needed to recognize the
> > declaration. I can't think of a good reason to add
On Sunday, 25 December 2022 at 02:34:35 UTC+11 Doug Kearns wrote:
> On Mon, 19 Dec 2022 at 00:33, Bram Moolenaar wrote:
>
>>
>> One thing I'm not yet sure about is the declaration. Currently it works
>> like this:
>>
>> this.name: string
>> this.gender: Gender
>>
>> Notice
On Saturday, 24 December 2022 at 04:40:15 UTC+11 bfrg wrote:
> > No, I prefer 'this' over 'self'. I was considering if its possible to
> go without any keyword for it. For example, these days we also have
> syntax highlighting which can give a different color for member variables
> and
On Mon, 19 Dec 2022 at 00:33, Bram Moolenaar wrote:
>
> One thing I'm not yet sure about is the declaration. Currently it works
> like this:
>
> this.name: string
> this.gender: Gender
>
> Notice that there is no "var" keyword. It's not needed to recognize the
> declaration. I
Sometimes quantity is quality.
self
. Python
. Smalltalk
. Lua
. Ruby
. Rust
. Legacy vimscript dict obj
this
. Dart
. C++
. Java
. C#
. Php use $this->
Neither this or self, but instance.member
.Julia
.Actionscript 3
. Fortran 90, 2003
Instance created by new
> No, I prefer 'this' over 'self'. I was considering if its possible to
go without any keyword for it. For example, these days we also have
syntax highlighting which can give a different color for member variables
and arguments.
In order to give different colors for member variables and
> Before everything becomes unchangeable, can I suggest to use
> "new ClassName" instead of "ClassName.new" to create an instance ?
>
> According to the description in vim9class.txt:
>
>
> > An object can only be created by a class. A class provides:
> > - A new() method, the constructor,
Hi Bram,
Before everything becomes unchangeable, can I suggest to use
"new ClassName" instead of "ClassName.new" to create an instance ?
According to the description in `vim9class.txt`:
> An object can only be created by a class. A class provides:
> - A new() method, the constructor, which
Hi Bram,
Before everything becomes unchangeable, can I suggest to use
"new ClassName" instead of "ClassName.new" to create an instance ?
According to the description in vim9class.txt:
> An object can only be created by a class. A class provides:
> - A new() method, the constructor, which
For what it's worth, I feel that the formal "var memberVariable : Type"
syntax for member is (while more verbose) more likely to stand out. The
`var` keyword is a signpost and so is likely to be syntax highlighted.
Simple `memberVariable : Type` doesn't stand out anywhere and contains
mostly
>
>
> The difference between a regular method and a constructor is that for a
> constructor it is very common to assign the argument to an object
> member.
>
> The idea comes from Dart, and I don't think Dart supports this for
> anything but constructors.
>
That's a good point, it is usually
> > class Blahh
> > toX: TYPE_A
> > toY: TYPE_B
> > fn SetXandY(toX, toY)
> > enfunc
> > endclass
>
> So... like you said, that was confusing.
>
> But, I just realised that prefixing member variables with "this" everywhere
> consistently could perhaps allow us to do something in between,
> class Blahh
> toX: TYPE_A
> toY: TYPE_B
> fn SetXandY(toX, toY)
> enfunc
> endclass
So... like you said, that was confusing.
But, I just realised that prefixing member variables with "this" everywhere
consistently could perhaps allow us to do something in between, along these
lines?
class
On Tuesday, 20 December 2022 at 01:26:15 UTC+11 Bram Moolenaar wrote:
>
> > I'm not a big fan of the "this" keyword. I agree if going to use it,
> > ensure to use it everywhere. Consistency is good. I like simplicity, and
> > dislike redundancy.
>
> What do you mean, do you prefer "self"?
>
> I'm not a big fan of the "this" keyword. I agree if going to use it,
> ensure to use it everywhere. Consistency is good. I like simplicity, and
> dislike redundancy.
What do you mean, do you prefer "self"?
> So, about "this", alternatively, don't use it anywhere, but maybe you
>
> > One thing I'm not yet sure about is the declaration. Currently it works
> > like this:
> >
> > this.name: string
> > this.gender: Gender
> >
> > and
>
> var name: string
> var gender: Gender
>
> to declare them.
That is indeed an alternative, and more like a normal declaration.
On Monday, 19 December 2022 at 19:52:34 UTC+11 Christopher Plewright wrote:
> I'm not a big fan of the "this" keyword. I agree if going to use it,
> ensure to use it everywhere. Consistency is good. I like simplicity, and
> dislike redundancy.
>
> So, about "this", alternatively, don't
I'm not a big fan of the "this" keyword. I agree if going to use it,
ensure to use it everywhere. Consistency is good. I like simplicity, and
dislike redundancy.
So, about "this", alternatively, don't use it anywhere, but maybe you
could throw an error if a function argument name is also
понедельник, 19 декабря 2022 г. в 00:33:24 UTC+11, Bram Moolenaar:
>
>
>
>
> For object members most languages use the "this." prefix. But not
> everywhere, which makes it inconsistent. A good example is a
> constructor where object members that are also an argument need to be
> prefixed
> Just to remember static meaning in C/C++ :
> ''
> A static variable inside a function keeps its value between invocations ''.
> https://stackoverflow.com/questions/572547/what-does-static-mean-in-c/572550#572550
We don't have static variables inside a function. Perhaps some day.
In a class
Hi Bram,
Just to remember static meaning in C/C++ :
''
A static variable inside a function keeps its value between invocations ''.
https://stackoverflow.com/questions/572547/what-does-static-mean-in-c/572550#572550
In C++ static class purpose is helper class and don't need to be
You may have noticed I started implementing classes for Vim9 script.
There are quite a few detailed choices to make. I have already written
the documentation with the current ideas: ":help vim9class". But
nothing is set in stone yet, we can discuss improvements.
One thing where different
62 matches
Mail list logo
