As an experiment, I had recently started work on implementing the reverse of this (extracting the implicit interface given a type) in a pull request for astrieanna's TypeCheck.jl package:
https://github.com/vtjnash/TypeCheck.jl/commit/b0ebcac4c2a9a3daccd1eeb1b28030b90ae5e2c9 On Tue, Jul 8, 2014 at 5:56 PM, Tobias Knopp <[email protected]> wrote: > Abraham, you might also be interested in the prototype that I have > prepared in https://github.com/JuliaLang/julia/pull/7025 > > While I am also looking forward that anything like this lands in Julia, > this is mainly about getting better error messages and code organization. > Julia is perfectly usable even with its implicit interfaces that are > available now. > > By the way, in the Base Graphics module there is a "mustimplement" macro > that also can be used to define interfaces. > > Am Dienstag, 8. Juli 2014 22:02:52 UTC+2 schrieb Stefan Karpinski: >> >> Definitely a missing piece. Here's the relevant issue: >> https://github.com/JuliaLang/julia/issues/6975. It's largely a question >> of design and implementation. >> >> >> On Tue, Jul 8, 2014 at 12:56 PM, Abraham Egnor <[email protected]> wrote: >> >>> I'm very new to Julia, so my apologies for the bits I inevitably get >>> wrong. >>> >>> As far as I can tell, Julia has no notion of interface, i.e. "if you >>> declare your data type a subtype of Foo, you also must/should implement >>> these functions on the type". This seems like a pretty significant lack to >>> me - it turns the (otherwise quite lovely) type system into essentially >>> tagged duck typing. >>> >>> There are a few packages that implement their own version of interfaces >>> (and it speaks well of Julia that this is possible!), but they do so with >>> very different semantics and don't expose any sort of general >>> interface-construction machinery. >>> >>> Are there any proposals for an interface framework as part of the >>> standard library? >>> >> >>
