> 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.
--
--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/u9b156%24bjn%241%40ciao.gmane.io.
Thursday, July 20, 2023
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment