# Enforce interface implementation
**URL:** https://discourse.julialang.org/t/enforce-interface-implementation/52872
**Category:** General Usage
**Created:** [January 5, 2021, 9:36am UTC](https://discourse.julialang.org/t/enforce-interface-implementation/52872 "2021-01-05T09:36:00Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@Iulian.Cioarca](https://discourse.julialang.org/u/Iulian.Cioarca)
#### Post date: [January 5, 2021, 9:36am UTC](https://discourse.julialang.org/t/enforce-interface-implementation/52872/1 "2021-01-05T09:36:00Z")
I’m trying to refactor [GenericInstruments.jl](https://github.com/iuliancioarca/GenericInstruments.jl) in order to play nicer with instrument front panels GUIs for our online university labs.
The problem is the following: different instruments keep popping up and the code needs to be compliant with the interface defined for the GUIs.
For example, let’s say that a GUI for a power supply needs two methods: `set_voltage(instr, val)` and `get_voltage(instr)` in order to set the psu and to read it. The reality is not that simple for other instruments which have tens of methods.
How can I enforce development of a driver for a new instrument to be compliant with the necesities of the GUI? Let’s say a new contributor does this.
Should I tell him to go and implement all the methods described in the documentation? In Matlab there are abstract classed which you can inherit from: if you forgot to implement one of the methods defined in the abstract class it yells at you.
---
### Author:  [@JeffreySarnoff](https://discourse.julialang.org/u/JeffreySarnoff)
#### Post date: [January 5, 2021, 10:02am UTC](https://discourse.julialang.org/t/enforce-interface-implementation/52872/2 "2021-01-05T10:02:18Z")
You should direct them to your GUI API documentation. Additionally, you may provide a test-for-compliance program to be run after the new instrument driver has been brought into Julia.
```julia
using NewDriver
using DriverCompliance
test_driver_compliance()
```
where a simple test could be
```julia
const required_api_funcs = (:get_voltage, :set_voltage)
function test_driver_compliance()
result = true
for fn in required_api_funcs
result = result && isdefined(Main, fn)
end
return result
end
```
You may want to check for appropriate method signatures, and to list any missing or incorrectly argumented functions.
---
### Author:  [@lmiq](https://discourse.julialang.org/u/lmiq)
#### Post date: [January 5, 2021, 10:39am UTC](https://discourse.julialang.org/t/enforce-interface-implementation/52872/3 "2021-01-05T10:39:05Z")
This book: [Hands-On Design Patterns and Best Practices with Julia | Packt](https://www.packtpub.com/product/hands-on-design-patterns-and-best-practices-with-julia/9781838648817)
Has a section about the implementation of interfaces which appears to be similar to what you are searching for. The ebook is for 5 pounds now, so it might be an interesting reference.
---
### Author:  [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)
#### Post date: [January 5, 2021, 10:42am UTC](https://discourse.julialang.org/t/enforce-interface-implementation/52872/4 "2021-01-05T10:42:17Z")
> [@Iulian.Cioarca](#):
>
> How can I enforce development of a driver for a new instrument to be compliant with the necesities of the GUI?
You can’t really “enforce” it in Julia. Eg even if you require a particular method signature, it may just return a bogus result (of the wrong type, or value).
I just would provide a test suite for the interface in a small package.
---
### Author:  [@Henrique\_Becker](https://discourse.julialang.org/u/Henrique_Becker)
#### Post date: [January 5, 2021, 12:55pm UTC](https://discourse.julialang.org/t/enforce-interface-implementation/52872/5 "2021-01-05T12:55:16Z")
I am currently reading that book. I did look back at the interface implementation section and basically it boils down to: define `function f(Any...) error("Should be implemented by the concrete type.") end` and creating a test suite that can be called over a type to check if it implements the promised behavior (or, at least, does not throw that error message).
---
### Author:  [@lmiq](https://discourse.julialang.org/u/lmiq)
#### Post date: [January 5, 2021, 2:01pm UTC](https://discourse.julialang.org/t/enforce-interface-implementation/52872/6 "2021-01-05T14:01:40Z")
Well, I would not say that it is only that, but it is effectively something simple. Yet, I am not comfortable in just showing what the book says, since it is being sold almost for free… The author deserves some credit.
---
### Author:  [@Iulian.Cioarca](https://discourse.julialang.org/u/Iulian.Cioarca)
#### Post date: [January 5, 2021, 2:04pm UTC](https://discourse.julialang.org/t/enforce-interface-implementation/52872/7 "2021-01-05T14:04:40Z")
Thank you all for your suggestions! I also bought the book and looking into it.
---
### Author:  [@baggepinnen](https://discourse.julialang.org/u/baggepinnen)
#### Post date: [January 5, 2021, 7:19pm UTC](https://discourse.julialang.org/t/enforce-interface-implementation/52872/8 "2021-01-05T19:19:47Z")
I previously solved this issue by simply providing a template file with empty functions for the person implementing the interface to fill in. It’s not very glamorous, but it solved the problem very effectively. It had the added benefit of making various implementations similar in terms of the file structure, making the code easier to navigate.
On a side note: my situation was also to provide implementations for university lab equipment, in my case for processes for automatic control 🙂
---
### Author:  [@Iulian.Cioarca](https://discourse.julialang.org/u/Iulian.Cioarca)
#### Post date: [January 5, 2021, 7:49pm UTC](https://discourse.julialang.org/t/enforce-interface-implementation/52872/9 "2021-01-05T19:49:36Z")
I also used this method in the past, it also worked as a rough documentation. Might give it a try again.
As for the lab, we’re using the GUIs mainly for debugging purposes, hoping the students still feel at least a bit connected to the hardware. The main purpose is to control the equipment remotely and teach them how large scale measurements are really done in the industry. Equipment changes, now I’m struggling to integrate the C++ library of ADALM2000 😅
---
### Author:  [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)
#### Post date: [January 9, 2021, 1:52pm UTC](https://discourse.julialang.org/t/enforce-interface-implementation/52872/10 "2021-01-09T13:52:52Z")
I didn’t read the book so I am not responding to that, but in general I don’t think that defining functions to just throw an error indicating that someone should implement a method is good practice, instead of just getting a `MethodError` — after all, that’s what it is for.
---
### Author:  [@Henrique\_Becker](https://discourse.julialang.org/u/Henrique_Becker)
#### Post date: [January 9, 2021, 2:10pm UTC](https://discourse.julialang.org/t/enforce-interface-implementation/52872/11 "2021-01-09T14:10:53Z")
I guess it depends on how much you want to give your users _training wheels_. While it is probably not a good practice in general (meaning you always should do it if possible), I see no reason to consider it a bad practice in general either.
---
### Author:  [@tisztamo](https://discourse.julialang.org/u/tisztamo)
#### Post date: [January 9, 2021, 2:28pm UTC](https://discourse.julialang.org/t/enforce-interface-implementation/52872/12 "2021-01-09T14:28:35Z")
[BinaryTraits.jl](https://tk3369.github.io/BinaryTraits.jl/dev/) (from @tk3369 , the author of the book) has signature checking feature, it’s worth taking a look.
> [@Tamas\_Papp](#):
>
> I just would provide a test suite for the interface in a small package
I was recently in the same situation, and ended up creating a separated test package where the code is in the src folder so it can be easily called from the tests of other packages. I am happy with it exactly because it also tests requirements that are not described in the signature.
---
### Author:  [@oxinabox](https://discourse.julialang.org/u/oxinabox)
#### Post date: [January 9, 2021, 7:31pm UTC](https://discourse.julialang.org/t/enforce-interface-implementation/52872/13 "2021-01-09T19:31:56Z")
One of my collegues wrote a blog post about this pattern of supplying a test suite function
> **[Development with Interface Packages](https://invenia.github.io/blog/2020/11/06/interfacetesting/#the-test-suite)**
>
> Over the last two years, our Julia codebase has grown in size and complexity, and is now the centerpiece of both our operations and research. This implies that we need to routinely replace parts of the system like puzzle pieces, and carefully test if...
It works really well.
I think [FilesPathsBase.jl](https://github.com/rofinn/FilePathsBase.jl/blob/5e7da1f9ff504733ca56a838081337187277cd17/src/test.jl)
is a good example of this pattern.
as is [Models.jl](https://github.com/invenia/Models.jl/blob/83e562b1bcf2b5cbf9b1fff257ab2034b79f5a5a/src/test_utils.jl#L130)
---
### Author:  [@tk3369](https://discourse.julialang.org/u/tk3369)
#### Post date: [January 9, 2021, 8:06pm UTC](https://discourse.julialang.org/t/enforce-interface-implementation/52872/14 "2021-01-09T20:06:06Z")
Since there’s a reference about my book, I should probably voice my opinion 🙂
I think it depends on the intended usage and audience.
- As a application developer, I may want to see a `MethodError` for missing implementations because it’s what I normally get when I make a mistake in my code and the quickest way to get to the problem.
- As a user of some third-party package, I may want to see a nice error that says “oh, sorry, you have hit a bug. Please submit an issue at our github site XYZ”. I don’t consider this a good practice to let the users of your package receive these low-level method errors.
BinaryTraits.jl was created due to the lack of formal interface/traits support by the language. The problem that I intended to solve is to let the developer specify interface formally, and so an implementer of that interface can easily discover the interface requirements and verify the correctness of the implementation during unit testing.
I am happy to hear more perspectives about this matter.
---
### Author:  [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)
#### Post date: [January 10, 2021, 11:56am UTC](https://discourse.julialang.org/t/enforce-interface-implementation/52872/15 "2021-01-10T11:56:04Z")
FWIW, once one is writing code, there is no clear distinction between “developers” and “users”. It can be assumed that someone writing Julia code should be able to deal with a `MethodError`.
That said, user friendly messages can still be provided with [error hints](https://docs.julialang.org/en/v1.7-dev/base/base/#Base.Experimental.register_error_hint).
---
### Author:  [@Henrique\_Becker](https://discourse.julialang.org/u/Henrique_Becker)
#### Post date: [January 10, 2021, 3:50pm UTC](https://discourse.julialang.org/t/enforce-interface-implementation/52872/16 "2021-01-10T15:50:17Z")
This is a very interesting feature I did not know. Maybe when the LTS version has this feature the bad practice will be defining a custom error instead of using this “error hints”.
---
### Author:  [@oxinabox](https://discourse.julialang.org/u/oxinabox)
#### Post date: [January 10, 2021, 3:52pm UTC](https://discourse.julialang.org/t/enforce-interface-implementation/52872/17 "2021-01-10T15:52:56Z")
> [@Tamas\_Papp](#):
>
> That said, user friendly messages can still be provided with [error hints](https://docs.julialang.org/en/v1.7-dev/base/base/#Base.Experimental.register_error_hint).
That is a really cool idea.
Kind of lets you have your cake and eat it.
You can avoid the [antipattern of `NotImplementedException`](https://www.oxinabox.net/2020/04/19/Julia-Antipatterns.html#notimplemented-exceptions)
which can give less clear and useful information than a `MethodError` (see that linked blog post for an example);
while still also being able to give a bit of an extra human readable hint about what is most-likely wrong.
---
### Author:  [@Henrique\_Becker](https://discourse.julialang.org/u/Henrique_Becker)
#### Post date: [January 10, 2021, 3:55pm UTC](https://discourse.julialang.org/t/enforce-interface-implementation/52872/18 "2021-01-10T15:55:02Z")
I would not assume what you assume. Many libraries like JuMP are used by people that have very little knowledge of Julia and benefit from training wheels, many do not have reasons to learn the language deeply just to use the features they intend to use and I would find obnoxious to try to force them to learn more advanced concepts instead of pointing out they probably forgot a parentheses or something like that.
---
### Author:  [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)
#### Post date: [January 18, 2021, 2:00pm UTC](https://discourse.julialang.org/t/enforce-interface-implementation/52872/19 "2021-01-18T14:00:06Z")
Yes, libraries that expose their API primarily via a DSL can benefit from nicer error messages, and ideally validating input to the extent possible so that errors are caught early.
My point is that _if_ you have an API which takes user-defined types that should conform to some kind of interface,
1. it is reasonable to assume that the user can deal with a backtrace,
2. providing a test suite is the best option if you want to be really nice to your users — it can cover way more than simple “does this method exist” checks and go into semantics,
3. error hints can be a lightweight alternative to 2. in simple cases.
---
### Author:  [@Dustin\_Hess](https://discourse.julialang.org/u/Dustin_Hess)
#### Post date: [February 15, 2022, 6:47pm UTC](https://discourse.julialang.org/t/enforce-interface-implementation/52872/20 "2022-02-15T18:47:45Z")
Also I would point out here that having formal interfaces is very useful when working larger projects. You can have many people developing different pieces. They aren’t going to know much about what are working on. Nor should they. You should expose a clear interface for them to adhere to so they don’t have to read your code. It should be immediately clear what to implement in order to adhere to the interface. This saves time and reduces bugs. Languages such C# sharp do this very well. Personally I love Julia but in the informal interfaces make very it frustrating reuse code that in poorly documented. ( of which there is a lot.) I find my self wasting hours reading code. However if interfaces was formal It would just tell you what need implement. Sure you get method errors but you don’t get that until run the code. Any way I like C# interface enforcement. I whish Julia has something similar.
[Next page](https://discourse.julialang.org/t/enforce-interface-implementation/52872.md?page=2)