On Sun, Oct 1, 2023 at 4:16 PM Ernie Rael <err...@raelity.com> wrote:
> On 23/10/01 2:56 PM, Yegappan Lakshmanan wrote: > > > On Sun, Oct 1, 2023 at 11:06 AM Ernie Rael <err...@raelity.com> wrote: > >> On 23/10/01 6:44 AM, Yegappan Lakshmanan wrote: >> >> Hi, >> >> On Sun, Oct 1, 2023 at 5:17 AM shane qian <shane.q...@live.com> wrote: >> >>> and I meant vim9script so far I felt it's good for type-checking and >>> performance, but vim9 class to me I felt a bit burdened, not sure if >>> still a chance to make it be simple to use (use for scripting), still wish >>> that's the goal. @errael @yegappan >>> >>> >> I haven't introduced any fancy OOP features so far. These are the >> features >> that Bram has partially implemented or planned for and were already in >> the todo list. >> >> The spec clearly says (said) >> >> Object methods of the base class can be overruled. *The signature >> (arguments,* >> *argument types and return type) must be exactly the same*. The method >> of the >> base class can be called by prefixing "super.". >> >> I can't find where Bram partially implemented or planned to allow >> contravariant parameters. In fact it looks the other way around. See >> comments >> https://github.com/vim/vim/pull/13221#issuecomment-1741637630 . >> >> After we've all worked hard to resolve incomplete spec issues (thinking >> statics) and to get the implementation to meet the spec. This last minute >> spec change, which doesn't seem to offer any useful functionality and >> hasn't been discussed or tested, feels ill-conceived. >> > > We have two options for the method parameter types. > > > Actually, we have *three options*. We could follow the original spec > which is invariant parameters: The signature [...] must be exactly the same. > > I've been repeating myself. But I still have not seen any answer as to why > the spec, invariant parameters, should be changed rather than simply > enforcing the spec for vim9.1, and revisiting > the issue at some future point. I'd be interested in seeing a real world > example that makes this > change worthwhile. > I have created PR https://github.com/vim/vim/pull/13248 to use invariant type check instead of contra-variant type check for the derived method argument type checks. We can revisit this type check later. - Yegappan > To be clear, if a method signature says "def Foo(): return A", that > doesn't mean that a subclass of A can't be returned from Foo(). > > We can either follow the Typescript/Java > specification, which supports covariance for the method parameters or > follow the Dart specification > which supports contra-variance for the method parameters. As we are > already following the Dart > specification for interfaces, I choose the Dart specification. > > > So what if we chose Dart for one thing. There are some cases where other > languages are followed, the idea is to pick something consistent with the > vim9script design philosophy. I do not understand why change the spec for a > confusing concept. I've only seen contravariant parameters in relationship > to generics, for example > > In the common case of a generic data structure ilist, covariant parameters > are used for methods getting data out of the structure, and contravariant > parameters for methods putting data into the structure. the mnemonic for > Producer Extends, Consumer Super (PECS), from the book Effective Java by > Joshua Bloch gives an easy way to remember when to use covariance and > contravariance. > > But in our case we are not talking about a generic data structures. And no > matter what words you use to describe it, it is not a simple concept. I > still review PECS when I design a Java generic class/method. IIRC, generics > are on the vim9class todo list; that's probably the proper time to consider > contravariant parameters. > > -ernie > > > >> While this may be something for the future, *I see no reason to change >> the spec now*. >> >> These features are basic to any OOP language. >> >> Can you point to a language that doesn't have overloaded methods that >> allows contravariant parameters? I'm not saying there aren't any (I'm just >> a country language-lawyer). >> > > Are you referring to covariant parameters here? If you are, then Dart > allows only contravariant parameters > for overloaded methods. > > Regards, > Yegappan > > >> > -- -- 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/CAAW7x7%3DhFSqf28Oj_en5y%3D0Sqer%3DfJESfe9iwuQm0FrmHyA7cw%40mail.gmail.com.
