Interface inheritance: use abstract types rather than symbols for optional components?

[rafaqz]

Each optional component would (hidden in the macro) define the abstract type like:

abstract type SomeInterface_option <: SomeInterface end

We could make it nicer looking, but that's the direct translation from what we have now

First we can just inherit the main interface

@interface NewInterface <: BaseInterface NewObject conditions 

But we could also inherit the optional component, which itself inherits the interface:

@interface NewInterface <: BaseInterface_opional_thing NewObject conditions 

We would test the interface by iterating over supertype until we hit AbstractInterface then working backwards, so the basal interface is tested first. When @@implements has multiple options, we would take the union of the interfaces to test at each step to avoid duplicating any tests..

But... what we really want is a hack for multiple inheritance:

@interface NewInterface <: Union{BaseInterface_option,SomeInterface} NewType conditions

Where we would drop the real inheritance and instead write something like:

abstract type NewInterface{T} <: Interface{T} end
inherits(::Type{<:NewInterface}) = (BaseInterface_option, SomeInterface)

Then all tests and trait queries would recurse over inherits(T) if a trait is false for T.

[gdalle]

I agree that inheriting interfaces is a key ingredient (see our recent Discourse discussion). Note that it is already possible at the moment, simply by adding Interfaces.test of the parent interface as a mandatory condition. So the key question is what we hope to achieve with a different syntax / implementation.

[rafaqz]

Yes its possible in the testing, but you don't get any traits to check that you passed it. The idea is that both tests and traits would be inherited automatically.

[rafaqz]

@gdalle I just realised having inheritance for options means we have to define the NamedTuple of options inside the macro so we can get the keys to define abstract types for them. So your changes allowing us to move objects out of the macro wont be able to be used.

[gdalle]

I'm kind of keen on that change, because hypothetically large interfaces could even span several code files

[rafaqz]

Sure, I guessed as much.

But: how do we get the NamedTuple keys into the macro as an expression. We cant inspect a variable in a macro and we cant define types later at runtime.

(You may need to choose nice layout or iheritance... or just move individual option functions to files and make all your options single lines calling those functions)

[gdalle]

If there's a choice I definitely go for inheritance.