>
>
> > 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, keeps it
> short and it's obvious what the variable is used for. What it does not
> work well for is when using an empty list or dictionary.
>
Thanks, that's good to know. I think type inference is generally useful.
Similar to how typescript does it.
So, I see how "var" could be helpful in distinguishing declarations from
assignments.
> > >>> 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?
> > >>
> > >
> > > It seems from the documentation that static fields can be referenced
> as
> > > bare identifiers? This feels a bit unexpected to me given that
> instance
> > > fields are always qualified.
> >
> > Just sharing another idea - perhaps also require "*static.*" as the
> class
> > scope prefix, and enforce it - for all the same reasons that "*this.*"
> > would be enforced as the object scope prefix.
>
> I don't know a language that does this. As I mentioned, the word
> "static" is a bit strange anyway, using it in more places makes that
> worse.
Yeah, that thought crossed my mind too.
> > Alternatively, perhaps we could use the actual class name as the
> enforced
> > prefix for static class scoped variables. Either option would avoid
> > confusion with inner function variables.
>
> Some languages use the class name as a prefix for class members.
> Outside of the class this makes sense, it's like a scope name. Inside
> the class, however, using the class name is more duplicating what you
> already know. With inheritance the question comes up if the current
> class name or the parent class name need to be used (maybe both work?).
> And class names have a tendency to be quite long.
Good question about inheritance. My initial thought is that either should
work. Now, hmm, if they aren't actually referring to the same thing? Not
sure. It seems odd for a static member to be shadowed by a child static
member variable. I think you could treat as with the standard inheritance
rules, ie, the child may specialize the parent's members. Doesn't matter
if they are static, ie, be consistent with inheritance for static class
functions as well as inheritance for static class variables.
That reminds me, in java, the compiler makes child default constructor
automatically call the super() default constructor, in cases where you
forget to write super() in the child constructor. The compiled bytecode
looks the same as if you had written super() in the code.
In java, the default constructor always refers to the zero-arg
constructor. But, I think you referred to the default constructor to be
able to initialise all the member variables. I do really like your idea
for that. So, for inheritance, if you have an existing parent default
constructor perhaps it should get called automatically when constructing
the child? I think maintaining that could be tricky if your child
constructor doesn't implement at least sufficient arguments to match the
parent's default constructor.
> There is also some similarity of using a script-local variable in code
> and functions inside that script. We currently don't use a prefix, and
> that works fine. I can predict that using class members inside the
> class can work without a prefix without a problem, just like using
> script-local variables.
>
> > Either way, it seems consistency is important here.
> >
> > The following is all over the place;
> >
> > var static oneClassMember: number
> > var static twoClassMember: string
> > this.threeObjectMember: number
> > this.fourObjectMember: string
>
> Using "var" is either for both or none, this mix is not making sense.
>
> > I think that the following also looks inconsistent;
> >
> > static oneClassMember: number
> > static twoClassMember: string
> > this.threeObjectMember: number
> > this.fourObjectMember: string
>
> Class and object members *are* different, thus I don't think consistency
> is important here, or even a goal.
>
Oh, OK. In my mind, the only difference is their scope and lifetime, which
is what that prefix declares.
Effectively, "this." has become like an enforced "m_" prefix on object
member variable names.
Likewise, I was thinking that "static." could effectively become like an
enforced "s_" for static class variable names.
> > I think the following is better, more consistent, and this would be my
> > preference;
> >
> > static.oneClassMember: number
> > static.twoClassMember: string
> > this.threeObjectMember: number
> > this.fourObjectMember: string
>
> This goes against the syntax we know from any other language. Using
> "static" as a prefix looks weird to me.
>
Sure, it is weird, but this is a new programming language, anything new
might look weird. I also liked the s: prefix
> > I don't mind var, but I don't see a real need for it either, because the
> > declarations will have the type name included. Anyway, if going to use
> > var, please keep it consistent, eg like this;
> >
> > var static.oneClassMember: number
> > var static.twoClassMember: string
> > var this.threeObjectMember: number
> > var this.fourObjectMember: string
>
> Whether to use "var" or not was also part of the discussion. It does
> make it clearer that we're looking at a declaraction. But otherwise the
> "var" keyword is not actually needed.
>
> I also wonder if it should be "var static oneClassMember" or
> "static var oneClassMember". Just using "static oneClassMember" avoids
> that. That still leaves open the possibility to use:
>
> static oneClassMember: number
> var this.oneObjectMember: number
>
> Or:
>
> static oneClassMember: number
> this.oneObjectMember: number
>
>
So, have you ruled out the following?
var static oneClassMember: number
var this.oneObjectMember: number
If you have ruled that out, then I think the following is the better choice
from the two you presented.
static oneClassMember: number
this.oneObjectMember: number
Now, wondering about the need for static in the first place. Just
stepping back to clarify some assumptions here.
Given that "static" has the same lifetime as a global variable, it only
differs in how you access it, is it really valuable.
Why implement it, if it is only an edge case - and global variables work
well already.
Another thought, vimscript had a great thing using letter-colon prefixes to
scope the variables. That looked really weird to me at first, but I really
like it now.
I assume you are still maintaining much of this list?
g: Global variable
{nothing} Global variable
b: Buffer-local variable
w: Window-local variable
t: Tab-local variable
s: Sourced Vimscript variable
l: Function local variable
a: Function formal parameter variable
v: Built-in Vim variable
Why not just add "c:" instead of "static" for *C*lass variables,
or perhaps even extend "s:" if it is declared inside a class definition?
Or, even extend "g:" here, to specify the lifetime as global, but whenever
g: is declared inside a class definition, then need to access it externally
via class-name prefix.
And why not use "o:" instead of "this." for object member variables?
Are you going to have a mixture of scope specifier patterns? Some from
good-Ol' vimscript and some common keywords from other languages?
--
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/3471006a-e6d6-404c-8a2f-31ffdc101188n%40googlegroups.com.
