[vim9class] object implements builtin-interfaces to interoperate with builtin-functions

[errael]

PR #13238 has a mechanism that allows objects to be used with builtin functions.
It is based on an object implementing a vim builtin interface. Use this discussion
to comment on, and provide feedback about, this approach.

See the PR and its help for details.

[errael]

Here's a simple example that demonstrates what is implemented so far.

class C implements vimObject, vimContainer
    var _size: number

    def String(): string
        return printf("{Object 'C' with %d elements}", this._size)
    enddef

    def Empty(): bool
        return this._size == 0
    enddef

    def Len(): number
    return this._size
    enddef
endclass

var o = C.new(3)
echo o o->empty() o->len()

outputs

{Object 'C' with 3 elements} 0 3

[errael]

Should Equals(other) be part of vimObject (or an optional part) and used by ==.

I guess the idea of "optional part" might mean that a builtin interface could have methods with a default implementation. Or maybe having vimEquals is better?

[yegappan]

I ran into this issue (optional methods) when modifying the tests to use the builtin interfaces. When extending an interface, all the methods in the interface must be implemented. There are no optional methods in an interface. When adding a test for the Empty() object method, I had to add the Len() method and vice versa. As we add more methods to these builtin interfaces, the class extending these interfaces must implement the interface methods. This may also cause backward compatibility problems in the future when adding new methods to the vimContainer interface.

[errael]

Allowing an interface to extend multiple interfaces may become more useful

interface MyContainer extends vimObject, vimEquals, vimContainer

[yegappan]

@errael : Thanks for opening this discussion.

[yegappan]

To support backward compatibility we cannot add new methods to builtin interfaces (e.g. vimContainer) in the future. So we need to create one builtin interface per method. This will result in too many builtin interfaces. This raises the question, do we really need the builtin interfaces? I think supporting just the builtin methods (e.g. len(), empty(), string(), etc.) is sufficient. This will allow us to add additional methods in the future without breaking backward compatibility. A class also can implement only the builtin methods that it supports.

[chrisbra]

I think this makes sense. Thanks

[errael]

This will result in too many builtin interfaces
... A class also can implement only the builtin methods that it supports

What's the problem with having a lot of builtin interfaces?

Additionally, from a programmer's perspective, string() and empty() and ==
already have a default implementation. For example, vimObject could include
String(), Empty(), Equals() with default implementations. Only override
what's needed. This could be one interface and not three.

To support backward compatibility we cannot add new methods to builtin
interfaces (e.g. vimContainer) in the future.

That argues for having a complete design and burnin period until released,
much like vim9.1 was handled. And if more methods are needed in the future,
they could be added with default implementations and/or a new interface name
could be introduced which extends the original.

Without having an idea of future plans/direction, it's hard to discuss. It
might be easier to explore possibilities from a design document rather than an
implementation; the language as a whole, how things fit together...

Here are some of the points that have been brought up, mostly about vim9script
developer advantages with having interfaces

1. commonly (universally?) used in strongly typed languages
2. get compile time errors, e.g. missing method, instead of runtime errors
3. it's obvious from the implements clause how a class can be used
4. the class requirements for a type of container/object are clear
5. programmatically determine if an object supports a method/interface

There's little comment from the vim team on what the community had to say. It
may be that the community has it wrong or isn't looking at builtins from the
right perspective.

[yegappan]

This will result in too many builtin interfaces
... A class also can implement only the builtin methods that it supports

What's the problem with having a lot of builtin interfaces?

If we use one builtin interface for every builtin method, then I don't see
a significant advantage in using a separate builtin interface (compared to
just supporting the builtin method).

Additionally, from a programmer's perspective, string() and empty() and == already have a default implementation.

The default implementation of empty() and "==" are not sufficient for a container object.

For example, vimObject could include String(), Empty(), Equals() with default implementations.
Only override what's needed. This could be one interface and not three.

The "vimObject" interface cannot be extended in the future (as it will break backward compatibility).
We cannot add a default implementation for a method in an interface. We need to change
"vimObject" to a class instead of an interface.

To support backward compatibility we cannot add new methods to builtin
interfaces (e.g. vimContainer) in the future.

That argues for having a complete design and burnin period until released, much like vim9.1 was handled. And if more methods are needed in the future, they could be added with default implementations and/or a new interface name could be introduced which extends the original.

Without having an idea of future plans/direction, it's hard to discuss. It might be easier to explore possibilities from a design document rather than an implementation; the language as a whole, how things fit together...

Here are some of the points that have been brought up, mostly about vim9script developer advantages with having interfaces

1. commonly (universally?) used in strongly typed languages
2. get compile time errors, e.g. missing method, instead of runtime errors

If we support default implementation for the builtin methods, then there won't be
any compile time errors.

3. it's obvious from the implements clause how a class can be used
4. the class requirements for a type of container/object are clear

As discussed previously, if we use one interface per method, then this will
not make the code simpler (you will have a very long line of implements).

5. programmatically determine if an object supports a method/interface

If there are default implementations for these methods, then how will you
determine whether an object uses a default method or a class specific
method? You can use exists() to check whether a class/object supports
a method. This works at script-level but doesn't work inside a def function.

There's little comment from the vim team on what the community had to say.
It may be that the community has it wrong or isn't looking at builtins from the
right perspective.

I did create multiple draft PRs with both the implementations to get the comments.