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 class method (or should it be called class function?) be static?
For example, a method accessed like

   MyClass.SomeStaticFunction()


Amusingly, I added a getter for the classMember; I guess accessing a static
member from inside the class definition is not handled yet. Different errors
depending on how it's accessed by the instance method

-ernie

   vim9script

   class MyClass
      public this.instanceMember: string
      public static classMember = 'foo'

      def new(instanceMember: string)
          this.instanceMember = instanceMember
      enddef

      def GetCM(): string
        return 'foobar'

        # following gets: Variable not found: classMember
        #return classMember

        # following gets: compile_class_object_index: not handled
        #return MyClass.classMember
      enddef

   endclass

   var c = MyClass.new("abc")
   echomsg c.instanceMember
   echomsg MyClass.classMember

   echomsg c.GetCM()

   # fails
   echomsg c.classMember



On 22/12/18 5:33 AM, Bram Moolenaar wrote:
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 languages have a different way of doing things
is how object and class members are declared.  Some are very verbose and
offer detailed options for access, others are so concise it's hard to
spot declarations and some have hardly any access control.  For Vim9 the
goal is to keep it simple, only support the features we really need, use
a simple syntax.

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 with "this." to avoid a name collision, while other object
members are used without "this.".  I find that very confusing.  Example:

        SomeObject(String name)
        {
          this.name = name;
          gender = Gender.unknown;
        }

Here both "name and "gender" are object members, but used differently,
because "name" is also an argument.

I looked into using the "this." prefix for object members everywhere,
and that turns out to work very well.  It's not really different from
what other languages are doing, it's not a new mechanism.  But instead
of using it optionally, require using it everywhere makes it consistent.

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 "var" here, other
than that a declaration would be expected to always have "var".  Well, I
don't have that expectation.

For class members most languages use the "static" keyword.  It's a bit
of a weird word, but I suppose most people are used to it, and I can't
find a popular language that has a good alternative.

If we leave out "var" for object members, I suppose we should also leave
it out for class members.  We then get:

        static oneClassMember: number
        static twoClassMember: string

I think this looks fine.  Any objections?



--
--
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/a279cfda-1e42-8ffb-d78f-d8594056bd28%40raelity.com.

Raspunde prin e-mail lui