> 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.
No comments:
Post a Comment