Am So., 11. Aug. 2019 um 22:04 Uhr schrieb Bram Moolenaar <b...@moolenaar.net>: > That is not at all we are doing. Function chaining has nothing to do > with OOP.
Definition of OOP is uninteresting/irrelevant here. > > 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 Vacuously true. *Functionality* is useful. *Features* often are useless noise, and only add entropy. Language-level features in particular. I reported my experience based on deep familiarity with Vim and Emacs plugin ecosystems. > 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. Back-compat is easier *for plugin authors* if they don't have to carefully select a subset of Vimscript. > > 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. It increases the cognitive burden (to plugin authors) of finding a backwards-compatible subset, and thereby makes back-compat a less common, higher-cost endeavor. > > > 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? You can suggest *any* language feature and you'll find people who want it. That's why C++ has all of them. So this survey is a formality. -- 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/CALbULwE737eMtFcvqcvR6KoBzqA54cs74MTXsZG14hCDr_M6aA%40mail.gmail.com.
