[vim9script] On extending interfaces

[Lifepillar]

Vim 9 script allows the following definitions, in which I2 extends I1 by
"implementing" it:

interface I1
def Foo()
endinterface

interface I2 implements I1
def Foo()
def Bar()
endinterface

The above compiles: I don't know whether it is intentional, but it is
pretty cool! Or, it would be if the following code worked:

def Echo(obj: I1)
obj.Foo()
enddef

class C2 implements I2
def Foo()
echo 'C2'
enddef

def Bar()
enddef
endclass

const c2 = C2.new()
Echo(c2) # ERROR

This results in:

type mismatch, expected object<I1> but got object<C2>

But C2 does conform to I1! To fix the error, it is necessary to declare
all the interfaces implemented by C2, that is:

class C2 implements I1, I2
# etc.

I will mention two other minor issues:

- I2 must declare Foo() again: it would be nice if that definition could
be inferred.
- "implements" is not a very accurate description: "extends" would make
more sense, intuitively.

In summary, what I am asking is whether Vim could (or should) support
this syntax:

interface I1
def Foo()
endinterface

interface I2 extends I1
def Bar()
endinterface

with the following implications:

1. any class implementing I2 must implement both Foo() and Bar().
2. any object of a class implementing I2 may be used wherever an object
with type I1 is expected.

Thanks,
Life.

[Salman Halim]

I find Life's proposed syntax to be more how I would expect it to work where a child interface should be able to just add stuff without having to redeclare inherited methods. Also, if a concrete class has to implement both i1 and i2 explicitly, then i2 might as well not subclass i1.

Salman

--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/u990to%24rvl%241%40ciao.gmane.io.

[Lifepillar]

> Also, if a concrete class has to implement both i1 and i2 explicitly,
> then i2 might as well not subclass i1.

Right, that's the approach I am currently adopting, which is fine
because my interfaces are small.

I may add that the problem with an orthogonal approach such as this:

interface I1
def Foo()
endinterface

interface I2

def Bar()
endinterface

class C implements I1, I2
...
endclass

class D implements I1, I2
...
endclass

is that there is no type for "C or D" or, more generally, for something
that "implements both I1 and I2", e.g.:

def F(X: ???)
X.Foo()
X.Bar()
enddef

where ??? = "anything implementing both I1 and I2". So, my current best
approximation is:

interface I1
def Foo()
endinterface

interface I2 # (Virtually) extends I1

def Foo()
def Bar()
endinterface

class C implements I1, I2
...
endclass

class D implements I1, I2
...
endclass

def F(X: I2)
X.Foo()
X.Bar()

def G(Y: I1)
Y.Foo()

which is perfectly fine (both F() and G() will accept objects of class
C or D), although the repetition in I2 may become a tad inconvenient if
I1 is large. Hence, my proposal.

Life.