On 23/10/01 2:56 PM, Yegappan Lakshmanan wrote:
On Sun, Oct 1, 2023 at 11:06 AM Ernie Rael <[email protected]> wrote:
On 23/10/01 6:44 AM, Yegappan Lakshmanan wrote:
Hi,
On Sun, Oct 1, 2023 at 5:17 AM shane qian <[email protected]>
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.
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
[...]
I think using a formal type checking term like "covariance" and
"contra-variance"
confuses people to think that we are introducing fancy features.
But these are
just terms for describing the type check and not new features.
I don't believe that is accurate regarding contra-variant
parameters; that is new. And for returning a covariant type that
could already be done *without removing the requirement* that "the
signature ... must be exactly the same".
I could have
used "implement appropriate type check for method arguments and
return
types in extended classes".
--
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/CAAW7x7mPtLqJsD0w8a%3DODLj5V%3Dj4-OZ__TPbkC90AXz%3D5byNrw%40mail.gmail.com
<https://groups.google.com/d/msgid/vim_dev/CAAW7x7mPtLqJsD0w8a%3DODLj5V%3Dj4-OZ__TPbkC90AXz%3D5byNrw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/8f817f10-8305-83be-9df6-de1850eec9a1%40raelity.com.
