search

tk3369 / BinaryTraits.jl

Can do or not? It's easy. See https://tk3369.github.io/BinaryTraits.jl/dev/
MIT License
53 stars 3 forks source link

Mismatch of function signature in @implement macro vs. what's actually need to be implemented #11

Closed tk3369 closed 4 years ago

tk3369 commented 4 years ago

Since we use Holy Traits pattern, it does not fit well with the current interface specification check. For example, with holy traits we should expect an implementation of liftoff(::CanFly, ::Duck) rather than liftoff(::Duck) as specified in the @implement macro.

Is this a problem.... or not?

KlausC commented 4 years ago

If Duck has assigned the trait Fly there is only the confusing problem, that you could provide a standard implementation like liftoff(d::Duck) = liftoff(flytrait(d), d) and forget the real implementation. That tends to become more problematic, if Duck <: Bird and the standard method is liftoff(b::Bird) = ....

tk3369 commented 4 years ago

Providing the standard implementation pretty much mandates the use of holy trait dispatch. I think that would be too big of an assumption.

Another issue is when do we provide the standard implementation... when we @assign the type? If we do it that way then it contradicts with the other idea of having to complete all implementation before doing the assignment (and I quite like that idea).

Just curious - does this issue bother you... or not?

tk3369 commented 4 years ago

Your comment about Duck <: Bird brings up a new bug. If I assign an abstract type with some traits with interface contracts then I expect all subtypes to conform to those contracts as well. I have opened a new issue #30 for that.

KlausC commented 4 years ago

Just curious - does this issue bother you... or not?

Thinking about that again, no. I see 2 different purposes of the interface specification.

  1. Usage and documentation. Which methods are available and how are they called?
  2. Implementation control. Are all specified methods defined in a certain way?

The existing check is perfectly to support the first topic. How the methods are implemented (for example by delegating to a specialized function with Holy traits) remains responsibility of the implementer. If we wanted to police this implementation detail, we should provide another check method (check_holy for example).

tk3369 commented 4 years ago

I generally agree. I would rather not dictate how users will implement dispatch and whether they choose the holy trait trick or not. I'm closing this issue for now. As more usage of this package kick in, we may have a new perspective and re-open as necessary.