Language Specification: interface members

[errael]

(This deserves its own discussion, moved here from elsewhere)
@yegappan @chrisbra @dkearns

From @mg979
Speaking of interfaces, generally they only define methods, here they also allow members? It looks like another kind of inheritance that makes things much too complex, I'd say either make interface work as in go/c# (no data, just methods) if it's possible (and easy) or drop them.

From @errael
That's a different discussion, this one is about access control working, not language spec; let's not hijack this discussion. It's a good discussion to have, I don't see anything in the spec about interface members, maybe they're not needed. BTW, vim9script doesn't support multiple inheritance, so can't just drop them.

From @mg979
In the documentation there's only one example with a method, but the examples here show you can define members. I can't see the difference from abstract classes this way.

It seems the vim9script class has been inspired by java classes, but also there interfaces can't define instance members, only constants (that aren't supported here).

[errael]

there's only one example with a method ... can define members

Yeah, I missed that section when I first looked at the docs. And there's also

A class can declare its interface, the object members and methods, with a
named interface.

[errael]

@mg979 As you've mentioned elsewhere, vim9script does not have properties and doesn't need that complexity. Having a member in an interface, could be considered as part of how that concept is handled.

The fact that this doesn't appear in C# or go, and only in Java as constants, doesn't bother me. Vim is intended to be a scripting language but strongly typed and OOP capabilities (not to mention the very vim specific bits). To that end, the syntax of some concepts isn't identical. And there are performance considerations in how things are implemented.

A point to consider is whether or not properties should be part of an interface. If so, how can that be best handled? At what cost...

[errael]

can't see the difference from abstract classes this way.

Interesting, I can see that. One difference is that interface can't have a method implementation. (at least I'm assuming they can't). But that seems minor to me.

It matters if you're refactoring. If you're using interfaces, then decide you want to add a property to the interface that's a problem. Which could argue for get rid of interface and use use abstract classes, but then multiple inheritance becomes an issue.

[mg979]

Multiple inheritance is to be avoided, interfaces are generally used instead of it, but they only declare methods, not members.

If I had to keep one of abstract classes and interfaces, I'd keep interfaces. But they shouldn't support members declaration.
vim9script class specification is already complex as-is, to even support multiple inheritance is a big no, for me.

An interface should only mean object x has method y(), you can call it, nothing else.

[errael]

keep interfaces. But they shouldn't support members declaration

You don't think properties should be part of an interface?

[mg979]

If by 'properties' you mean members, no other language does it. For interfaces they aren't needed.

If class Triangle and class Circle both have an interface with Surface(), no members are needed in the interface, how the classes calculate the surface is their own business. The same applies to all kind of interfaces.

[errael]

If by 'properties' you mean members, no other language does it. For interfaces they aren't needed.

I mean conceptually, not implementation. Conceptually, to me, it seems properties should be part of an interface.

If class Triangle and class Circle both have an interface with Surface(), no members are needed in the interface, how the classes calculate the surface is their own business

I agree that "how the classes calculate the surface is their own business".

But a member named size in no way say how that size should be calculated. I don't understand what you're saying.

Maybe what you mean is that you would rather see

def GetSize(): number

, instead of a member, in the interface and sacrifice the performance.

[mg979]

Maybe I wasn't clear.

I never used properties in python tbh, but if they're properties, they're functions, it's just syntactic sugar, there is no performance gain as you say, it's not different from having GetSize(). But I don't think vim9 should have properties, just methods. Maybe properties could stay in an interface (because they're functions), but regular variables have no reason to be in there. This is what I'm saying.

[errael]

And what I'm saying is that a member can be a property. And a reason for them to be there is that accessing them as a member is much higher performance. The downside of that, is that the value has to always be present, whereas if you had a function then the calculation could be deferred.

The programmer has the choice of using a function or a member for the property.

[errael]

I do think that a read/write member as a property makes no sense at all. Perhaps a member in an interface should be restricted to read-only members.

[mg979]

Now I get it. But other languages don't allow variables in interfaces (java only constants from what I can read around).

[mg979]

I still think it's a bad idea to have variables in interfaces. You have abstract/extended classes for that kind of things.

[mg979]

If instead by properties you mean functions disguised as members as you can see in other languages, then they're functions, not variables, and there is no performance gain.

Anyway here we don't have this kind of properties so it doesn't apply.

[errael]

we don't have this kind of properties

properties is a concept.

You don't like the implementation.

[dkearns]

Thanks for starting this. I haven't read through it yet, but before I forget Bram responded to one of my queries some time ago.

https://groups.google.com/g/vim_dev/c/yYpFNUHdRho/m/UTFWOY5VAgAJ

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.

[errael]

Sems to be resolved