Language Specification: Dedicated Interface Structures May Be Redundant

[dkearns]

It's currently slated to provide classes with the capability to define interfaces. See :help specifies.

It seems to me that it is worth exploring the possibility of removing explicit interface structures and folding them into this class based mechanism.

With this specifies feature I believe the following would declare an identical interface.

interface Foo
   def Bar(): void
endinterface

abstract class Baz specifies Foo
  abstract def Bar(): void
endclass

I mentioned this to Bram some time ago:

I notice that it's planned to allow classes to "specify" an interface.
Does this not make interfaces themselves redundant? I can't see any
utility to them over abstract classes that specify an interface.

An abstract class and an interface have several similarities. Some
languages do not even have interfaces and then you use an abstract class
instead.

An important difference is the intention. For an abstract class this is
not always clear, some people suggest to not have them at all for that
reason. For an interface the intention is very clear.

The idea to have a class (not abstract) specify an interface comes from
the life cycle of code. Also for testing purposes. Very often someone
creates a class, and only later there is a desire to have an interface,
which the class implements. Since this then requires quite a bit of
refactoring, some have suggested to always define an interface and a
separate class that implements that interface. Unfortunately that
causes a lot of duplication.

The mechanism that a class can function as an interface at the same time
solves these problems elegantly. It avoids defining an interface
separately, and it's easy to add the interface to the class later.
It is almost like having a tool that generates the interface from the
class.

Only a few languages have this mechanism, but I like it. We can
probably do without it for quite a while, thus implementing this has a
low priority.

I still think it would be worth exploring ways to remove the redundancy without losing "the intent". This would possibly result in removing standalone interfaces so it should be considered before any release.

[errael]

The idea to have a class (not abstract) specify an interface...

Is it a change, from the original spec, to allow specifies on an abstract class? It reads like specifies is used only on a concrete class.

So there would only be implicit interfaces? The programmer still needs to know about interfaces, there's still the implements keyword, and the relationship with multiple inheritance. What's the advantage to the programmer of requiring

abstract class Baz specifies Foo
  abstract def Bar(): void
endclass

instead of

interface Foo
   def Bar(): void
endinterface

(assuming in the original example, endclass was intended, not endinterface)

The former doesn't look simpler. It doesn't save any conceptual understanding.

Somewhat off topic,

Very often someone
creates a class, and only later there is a desire to have an interface,
which the class implements. Since this then requires quite a bit of
refactoring

Not especially relevant, but I don't see how that necessarily requires quite a bit of, or even any, refactoring. In any event, by the time a programmer needs it in their big project, let's hope specifies is available ;-)

[dkearns]

The idea to have a class (not abstract) specify an interface...

Is it a change, from the original spec, to allow specifies on an abstract class? It reads like specifies is used only on a concrete class.

I don't think so, it would be a bit strange to exclude abstract classes. I just read that as a generalisation - more exactly "not just abstract".

So there would only be implicit interfaces?

I think "specifies" makes the interface declaration explicit. Implicit would probably be used to describe the case where every class provided an interface regardless.

The programmer still needs to know about interfaces, there's still the implements keyword, and the relationship with multiple inheritance. What's the advantage to the programmer of requiring

abstract class Baz specifies Foo
  abstract def Bar(): void
endclass

instead of

interface Foo
   def Bar(): void
endinterface

One way to do it.

(assuming in the original example, endclass was intended, not endinterface)

Fixed.

The former doesn't look simpler. It doesn't save any conceptual understanding.

The syntax would hopefully be simplified. It saves having to understand that they're both describing, almost, the same thing.

Dart has already done the work here so if it's agreed that Bram had something similar in mind it would provide some guidance.

Here's the initial proposal to remove interfaces from Dart: https://news.dartlang.org/2012/06/proposal-to-eliminate-interface.html

Somewhat off topic,

Very often someone
creates a class, and only later there is a desire to have an interface,
which the class implements. Since this then requires quite a bit of
refactoring

Not especially relevant, but I don't see how that necessarily requires quite a bit of, or even any, refactoring. In any event, by the time a programmer needs it in their big project, let's hope specifies is available ;-)

Like anything, people have different views on how onerous a given refactoring might be.

[errael]

It saves having to understand that they're both describing, almost, the same thing.

One still has to understand at most one extends but any number of implements. It could be argued that that's the key concept; adding specifies converts something to almost the same thing as well. Are there a bunch of rules needed for what happens when you tack on specifies, maybe around constructors and statics? I guess something that has specifies can be used after either extends or implements with subtle differences. It could actually be more confusing. The simple choice for a programmer could be implements and if there are special requirements specifies can be used.

Bottom line for me, it just syntax, I can deal. But I don't see much, if any, advantage and possibly more complexity and confusion for programmers if the simpler interface is not available. One can just learn specifies ignore interface.

And there's lots that could be said about the practical implications of making such a change...

[dkearns]

As I understand it,

class Foo specifies IFoo
  def DoSomething(): void
    echomsg "Doing something"
  enddef
endclass

would be exactly the same as

class Foo
  def DoSomething(): void
    echomsg "Doing something"
   enddef
endclass

interface IFoo
  def DoSomething(): void
endinterface

and both used as expected

class A extends Foo
  def StopSomething(): void
    echomsg "Stop it"
  enddef
endclass

class B implements IFoo
  def DoSomething(): void
     echomsg "Doing something different"
  enddef
endclass

[errael]

In theory

class Foo specifies IFoo ...

is exactly the same as

interface IFoo ...
class Foo implements IFoo ...

I'd guess that in practice that's not the case. If I have a concrete class Foo it probably has things, for example private members and implementation specific helper methods, that should not be part of an interface. So it seems to really use class Foo specifies IFoo, then you need to design Foo specifically to use it with specifies (except maybe for the example where specifies is used to help create a class used with testing).

Also consider that if class Foo is something that is instantiated and does useful things in the codebase, and not just something to hang specifies on to get an interface, then in the example above, if you need to add something to Foo, then it also needs to get added to class B (class 'A' would pick it up with inheritance); that seems painful.

Ah, I think I see, the difference with specifies versus interface is that the dependency goes the other way. It introduces dependencies that aren't there when using interface.

Java introduced default methods on an interface, that's useful. It would be cool if specifies, or something, could help to get that capability.

[errael]

@dkearns

In #13069 (comment) the statement

would be exactly the same as

Is not accurate. (unless I'm still not understanding something).

How do you think this affects the exploration for

removing explicit interface structures

[dkearns]

The premise was that there would be a way to declare a strict interface using this "specifies" syntax - semantically identical to the current "interface" declaration.

The difficulties you mention are modelling concerns that exist with the proposed "specifies" anyway.

I don't know where the "specifies" idea came from but I assume it was Dart since it's mentioned in the help and discussions as one of the reference languages. We don't really need to wonder what this might look like, we can just look. :)

I don't feel that strongly about it and perhaps "specifies" will never be implemented.

[errael]

Considering what I've heard around this vim discussion, it seems there are two use cases for specifies.

1. To establish an interface so the class can be mocked for testing
2. An alternate way to define an interface.

For 2, it seems like specifies should only be applied to a class, which in turn is only used to specify the interface, otherwise it is too easy to experience unwanted side effects.