Bram says the same in some parts, but I'm one of users who appreciate -> operator was included.
> Justin What backward compatibility does this syntax sugars (type annotation and -> operator) break? I don't think this breaks backward compatibility. I understand if you think it's just unnecessary, but I don't think so. As Bram said, you can choose using -> operator or not. It is difficult to discuss about a syntax sugar is useful or not. Someone thinks it is useful, but the other may not. > Type-parameterized methods are usable in languages with IDEs. But I do > not think it makes sense to change Vimscript into a language that > requires an IDE: that is a regression, not an improvement. I write TypeScript in Vim. You might think about auto-completion by variable's type when typing "->". But it helps to avoid a lot of bugs of various errors. --- I see this operator (->) as pipeline operators in other languages (not method invocation), so maybe I see slightly the different point of view from Bram. and pipeline operator I was thinking is not related to type annotation (just passing lhs of -> to the function of rhs). Yes I proposed `var: type` syntax here... https://github.com/vim/vim/issues/4768#issuecomment-518021861 Because I supposed Bram sees -> operator as method invocation and wants to limit the type of value. I agree it should be discussed more carefully before the first commit. but there are no objections in the above issue. 2019年8月12日(月) 5:04 Bram Moolenaar <b...@moolenaar.net>: > > > Justin M. Keyes wrote: > > > Am So., 11. Aug. 2019 um 00:11 Uhr schrieb Bram Moolenaar > > <b...@moolenaar.net>: > > > Currently user functions can be used both without a context and as a > > > method, it is not possible to restrict them to be used as one or the > > > other. Very often this doesn't matter, the method is the same as the > > > function, passing the base as the first argument. But questions arise: > > [...] > > > What problem is being solved by adding these various OOP cosmetics to > > Vimscript, other than ticking a "I have this feature" checkbox? > > That is not at all we are doing. Function chaining has nothing to do > with OOP. > > > Historically, something that I strongly appreciated about Vim was its > > (now obviously accidental) culture of backwards-compatibility in the > > *plugin community*. This happened (accidentally) because Vimscript > > evolved so slowly, it was usually worth the effort for plugins to > > support 10-year-old versions of Vim. Contrast to Emacs, where I found > > most plugins required the latest version. > > That is not true, over time new functionality was added and quite often > plugins soon popped up which used this functionality, thus depended on > that new version. And old plugins keep working, that is what backwards > compatibility is about. If you see an old plugin break because of new > functionality, then please report it soon, that's not what we want. > > > With meaningless syntax-sugar being added into Vimscript, that > > accident will become much less frequent. Plugin authors can add > > wrappers for e.g. missing *library* functions. But they cannot add > > wrappers for syntax sugar. They could adopt a "subset" (like C++... > > does that sound familiar?) of VimL, but the general effect will be > > pollution of community knowledge as the discussion becomes more > > complicated, with code samples only working in recent Vim versions > > simply because someone writes foo->bar() instead of bar(foo). > > And don't see what wrappers are needed for new syntax. Just keep using > the old syntax. > > Every plugin writer will have to aim for a certain minimal Vim version. > If the plugin uses the new popup window feature, then older versions > will just not work. This is nothing new. Except perhaps I'm now adding > functionality requested by plugin writers about a year ago, thus it's > likely plugins will appear that use these new features. There is > nothing wrong with that. > > Today's version of Vim is new and not widely spread, but in a few years > it is, and then we'll be glad there is a better way to write Vim script. > > > Why in the world is foo->bar() worth sacrificing even a small amount > > of backwards compatibility, > > If you think this breaks backwards compatibility, please give an > example. > > > or worth complicating tutorials/documentation/discussions even a small > > amount? It is pure vanity. The same applies for these other > > meaningless OOP cosmetics (including "dict functions" which are harder > > to debug). > > I found myself writing Vim code this way, because it's very natural. > All modern languages use and recommend this, including Java and > Typescript, which are both very popular. > > > It is strange that these "fake OOP" features are being *amplified* in > > Vim now. What's the point? > > Again, this has nothing to do with OOP. > > > > I was first thinking of adding a property to the function command: > > > function Total(arg) method=list > > > function Total(arg) method=dict > > > > > > Many languages now support an optional type, using that we could do: > > > function Total(arg: list) method > > > function Total(arg: dict) method > > > > Type-parameterized methods are usable in languages with IDEs. But I do > > not think it makes sense to change Vimscript into a language that > > requires an IDE: that is a regression, not an improvement. > > I hardly ever use an IDE for any language, including Java and > Typescript. True, someone who is familiar with a good IDE can do > certain things faster, but these IDEs are lacking a good editor... > > Anyway, the real question I'm asking is if selecting a function/method > based on the type is actually useful or will just make things more > complicated? > > -- > hundred-and-one symptoms of being an internet addict: > 39. You move into a new house and decide to Netscape before you landscape. > > /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ > /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ > \\\ an exciting new programming language -- http://www.Zimbu.org /// > \\\ help me help AIDS victims -- http://ICCF-Holland.org /// > > -- > -- > 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/201908112004.x7BK4ZBt021173%40masaka.moolenaar.net. -- FUJIWARA Takuya -- -- 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/CAKEvVzvb%2B-Fq476HEmBmOXBYN-09AqNDKt2hPXaJvukapopTjg%40mail.gmail.com.
