> > > > 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.