Re: Proposal for User methods

2019-08-11 Fir de Conversatie Justin M. Keyes
Am So., 11. Aug. 2019 um 22:04 Uhr schrieb Bram Moolenaar : > 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 accident

Re: Proposal for User methods

2019-08-11 Fir de Conversatie FUJIWARA Takuya
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,

Re: Proposal for User methods

2019-08-11 Fir de Conversatie Bram Moolenaar
Justin M. Keyes wrote: > Am So., 11. Aug. 2019 um 00:11 Uhr schrieb Bram Moolenaar > : > > 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

Re: Proposal for User methods

2019-08-11 Fir de Conversatie 'Andy Wokula' via vim_dev
Am 11.08.2019 um 00:11 schrieb Bram Moolenaar: So if you intentionally want to define a function to both be used without a context and as a method, but still want to specify the type, we should allow for: function Total(arg: list) function Total(arg: dict) This basically means we

Re: Proposal for User methods

2019-08-11 Fir de Conversatie Ingo Karkat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11-Aug-2019 18:51 +0200, 'Andy Wokula' via vim_dev wrote: > Am 11.08.2019 um 18:27 schrieb Bram Moolenaar: >> I'm not sure about methods for a specific type, e.g. only defined >> for a list or dict. I suppose in many cases you have very >> simila

Re: Proposal for User methods

2019-08-11 Fir de Conversatie 'Andy Wokula' via vim_dev
Am 11.08.2019 um 18:27 schrieb Bram Moolenaar: I'm not sure about methods for a specific type, e.g. only defined for a list or dict. I suppose in many cases you have very similar functionality in both, and might as well define both. It would be possible to make the type available to the autocom

Re: Proposal for User methods

2019-08-11 Fir de Conversatie Bram Moolenaar
Andy Wokula wrote: > Am 11.08.2019 um 00:11 schrieb Bram Moolenaar: > > 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 > > func

Re: Proposal for User methods

2019-08-11 Fir de Conversatie 'Andy Wokula' via vim_dev
Am 11.08.2019 um 00:11 schrieb Bram Moolenaar: 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 ar

Re: Proposal for User methods

2019-08-11 Fir de Conversatie Justin M. Keyes
Am So., 11. Aug. 2019 um 00:11 Uhr schrieb Bram Moolenaar : > 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 b

Proposal for User methods

2019-08-10 Fir de Conversatie Bram Moolenaar
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 fu