Syntax/scope of interface definitions and implementations

[stemann]

Any thoughts on the syntax proposed in (the prior) https://github.com/quinnj/Interfaces.jl ?

E.g.,

abstract type Indexable end

@interface Indexable begin
    getindex(::Indexable, i)
    setindex!(::Indexable, v, i)
    firstindex(::Indexable)
    lastindex(::Indexable)
end

@test Interfaces.implements(Array, Indexable, [Base])

It is clear that the mandatory/optional tests in your interface definitions goes further than just ensuring that proper methods are defined - with the proper argument/return types.

Updated: Also:

• But why is something like [Duck(1), Duck(2)] needed in the @implements interface defintion? Fixed with Moved test objects to test method #10.
• And would it be more beneficial to handle optional parts of an interface with Hierarchy of interfaces #6 ? Leave this to a separate discussion.

[rafaqz]

It doesn't even have a readme so not really.

The reason for mandatory/optional is that interfaces are often complicated. A widely used package like StaticArrays.jl could not use Indexible in your example on SArray, because it has no setindex!. So there is no point putting setindex! and getindex in the same flat interface like that. But they do belong together somehow or other, and we don't want to define an interface for all possible combinations of method definitions. So we need to be able to specify what we implement and what we skip.

But, I can't even remember why Duck() is needed. If you can reorganise things so it isn't, go for it. This was just an idea over a weekend that got a bunch of stars but no feedback or users as far as I known, so I kind of moved on to more pressing concerns.

[stemann]

OK.

Good points.

Regarding the Duck()'s, it seems - after a first glance at the code - that the test_objects could be dropped from the @implements definitions - and instead be required for the implements method calls (as in Interfaces.implements(Animals.AnimalInterface, Chicken()))

[rafaqz]

Sure, that does seem cleaner. A PR would be nice :)

[rafaqz]

Hm actually maybe put them in the test method call? implements really needs to work on types.

[stemann]

OK - from here on, let this issue be solely about the first question - the merits of the quinnj syntax, cf. #10 (comment)

What do you think of the idea about having two ways of defining an interface? One with the "method signatures" syntax from quinnj, and one with the predicate syntax in v0.1.0 of this package?

Obviously, having two ways of doing one thing sounds alarming, but perhaps the method signatures syntax is more natural/appealing for people used to, e.g., a C# interface.

I'm thinking the macro could reasonably easy figure out which syntax is used and just define the predicates that correspond to testing the method signatures.

[rafaqz]

Yeah... its a little complicated to do both!

I used the function predicate approach because it can do pretty much anything, but that does come at the expense of style.

So this idea is about making the syntax slick? That is of course a valid goal.

If you can actually define a macro that does both, we can asses if it feels right to use it?

[rafaqz]

Closing this, from extensive use it doesn't look like the syntax needs to be any simpler