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 if the function doesn't take an argument, should it not be able > to be used as a method? Or always result in an error? Or should we > be able to define a function FooBar() without an argument to be used > as a function and a function FooBar() with an argument to be used as a > method: > func Report() > echo "nothing to report" > endfunc > func Report(msg) > echo "this happened: " .. a:msg > endfunc > > - What if I want to define a similar but different method depending on > the type of the first argument: > GetList()->Total() > GetDict()->Total() > Generally, define a method that gets used only if the context type > matches. > We already do this for internal functions: len() works differently > depending on the argument type. > > All can be done in some other way, but rather clumsy. We could try > supporting this better. >
What problem is being solved by adding these various OOP cosmetics to Vimscript, other than ticking a "I have this feature" checkbox? 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. 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). Why in the world is foo->bar() worth sacrificing even a small amount of backwards compatibility, 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). It is strange that these "fake OOP" features are being *amplified* in Vim now. What's the point? > 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. -- Justin M. Keyes -- -- 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/CALbULwF5KkebmeBDMJ5Ptp1uVVKrCaPcxd-TkzpA0j0n_CpgPw%40mail.gmail.com.
