# Where should conversion methods for types from different packages go?

**URL:** <https://discourse.julialang.org/t/where-should-conversion-methods-for-types-from-different-packages-go/2916>\
**Category:** General Usage\
**Created:** [March 28, 2017, 6:12am UTC](https://discourse.julialang.org/t/where-should-conversion-methods-for-types-from-different-packages-go/2916 "2017-03-28T06:12:37Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![mkborregaard](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mkborregaard/32/556_2.png) [@mkborregaard](https://discourse.julialang.org/u/mkborregaard)\
**Post date:** [March 28, 2017, 6:12am UTC](https://discourse.julialang.org/t/where-should-conversion-methods-for-types-from-different-packages-go/2916/1 "2017-03-28T06:12:37Z")

</div>

I think it would be great if the Julia ecosystem could stay connective but modular, so it doesn’t end up like the fragmented ecosystem of R. One thing that would be really nice is interoperability among different types used for different applications, but I am unsure how to do this in practice.

As always, an example makes it easier. Say I use the Quandl.jl package to download some financial data, which comes in the `TimeArray` format defined in the TimeSeries package. I then want to do a regression analysis on the data (e.g. to look for temporal autocorrelation), so I load the GLM package, which is easiest to use if your data is in a `DataFrame`. I can fairly easily write a `convert(DataFrame, x::TimeArray)` function for my project. But it seems like this is functionality that thousands of users may want to use thousands of times, so it’d be nice to make it available.

AFAICS there are two possibilities: 1) submit the `convert` function to either DataFrames or TimeSeries - this would incur a dependency on the other package for that package, and would almost certainly be unpalatable; or 2) create a new package ConvertTimeArraysToDataFramesAndViceVersa.jl, that depends on both, which seems like it could easily bloat the package ecosystem.

Any well-established solutions? Perhaps the fabled optional dependencies that may come with Pkg3?

---

<div class="post-metadata">

**Author:** ![andyferris](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/andyferris/32/235_2.png) [@andyferris](https://discourse.julialang.org/u/andyferris)\
**Post date:** [March 28, 2017, 9:34am UTC](https://discourse.julialang.org/t/where-should-conversion-methods-for-types-from-different-packages-go/2916/2 "2017-03-28T09:34:49Z")

</div>

I would say that optional dependencies should solve this problem.

---

<div class="post-metadata">

**Author:** ![nalimilan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nalimilan/32/147_2.png) [@nalimilan](https://discourse.julialang.org/u/nalimilan)\
**Post date:** [March 28, 2017, 11:58am UTC](https://discourse.julialang.org/t/where-should-conversion-methods-for-types-from-different-packages-go/2916/3 "2017-03-28T11:58:40Z")

</div>

Optional dependencies will help in general, but for the specific case you describe I think `TimeArray` should just implement the future `AbstractTable` interface so that GLM will be able to build a model matrix automatically (via StatsModels). DataStreams will also allow converting to and from `DataFrame` as well as to and from any type which implements this interface. It appears that Query.jl is already able to do this (see [this thread](https://github.com/JuliaStats/StatsModels.jl/issues/14)).

The interface will live in a small package on which all other tabular data packages will depend, and with optional dependencies it could even become optional.

---

<div class="post-metadata">

**Author:** ![mkborregaard](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mkborregaard/32/556_2.png) [@mkborregaard](https://discourse.julialang.org/u/mkborregaard)\
**Post date:** [March 28, 2017, 12:18pm UTC](https://discourse.julialang.org/t/where-should-conversion-methods-for-types-from-different-packages-go/2916/4 "2017-03-28T12:18:38Z")

</div>

Thanks, this is really helpful, as my question was also a more fundamental inquiry into the philosophy for cohesion in the julia package ecosystem. The idea of having generic interface that types can implement and then be generally compatible with functionality is a neat one - I am not sure I understand it and its implications completely, but it may become clearer as all these things click into place 🙂