I am learning how to make one library compatible with another. They both have different type hierarchies for representing a file path.
AbstractString, the other uses
SystemPath for their abstract representation of paths. Their use of low-level interfaces like
open() dispatch in a compatible way.
I don’t want to change the parameters of each high-level method to all be
I’d like to give that Union Type a name and use that to type the appropriate parameters.
Can I do that? If not, how should I express this?
And… it’s sort of distressing, because each library sort of shouldn’t have to know about each other.
I could almost make a mixin library which just contained functions to implement compatible dispatch.
Then I’d be making a patchwork. Which doesn’t seem great either.
I might not want the type restriction, in order to allow other pathlike types that haven’t been written yet.
Just making sure I understand…
So rather than adding another type in the parameter - as the Union, remove the type specification altogether.
That seems like a good idea, Then the peer library just provides methods to make itself work in the context - just like open(::PosixPath) does already?
That leaves both libraries not needing to reference each-other.
Right. Ideally julia would have a more flexible interface system so it could support something like a “pathlike” trait or specification, but that’s not currently available.
if you don’t need to do specialized things, you don’t need to clamp down types
we used to call that a
protocol in Smalltalk. A set of method names that instances had to understand to support a functionality. Like the
ReadStream protocol e.g.
#(#next #next: #atEnd), which could be implemented by classes which were unrelated in the class hierarchy. Then any object expecting
ReadStream could use them. No compiler support though