StatsBase is meant to occupy that sort of role, but there's enough disagreement that we haven't moved as far foward as I'd like. Have you read through the StatsBase codebase?
-- John On Dec 2, 2014, at 8:19 PM, Rob J. Goedman <[email protected]> wrote: > Thanks John, I’d come to a similar conclusion about there not being a > straightforward solution. Nice to get that confirmed from your side. Cutting > back on exporting names whenever possible also makes a lot of sense. > > Is StatsBase intended to play a similar role for types? Or is that more the > domain of PGM.jl? > > As an example, Model is used in several packages (MCMC, Mamba). This makes > using both packages simultaneously harder as the end user needs to figure out > which names to qualify. Other packages have taken a different approach. > MixedModels uses MixedModel and LinearMixedModel, GLM uses LmMod and GlmMod, > Stan and Jags use Stanmodel and Jagsmodel (I could rename them to StanModel > and JagsModel). Is it reasonable to make Model an abstract type? > > Rob > > >> On Dec 2, 2014, at 4:37 PM, John Myles White <[email protected]> >> wrote: >> >> There's no clean solution to this. In general, I'd argue that we should stop >> exporting so many names and encourage people to use qualified names much >> more often than we do right now. >> >> But for important abstractions, we can put them into StatsBase, which all >> stats packages should be derived from. >> >> -- John >> >> On Dec 2, 2014, at 4:34 PM, Rob J. Goedman <[email protected]> wrote: >> >>> I’ll try to give an example of my problem based on how I’ve seen it occur >>> in Stan.jl and Jags.jl. >>> >>> Both DataFrames.jl and Mamba.jl export describe(). Stan.jl relies on Mamba, >>> but neither Stan or Mamba need DataFrames. So DataFrames is not imported by >>> default. >>> >>> Recently someone used Stan and wanted to read in a .csv file and added >>> DataFrames to the using clause in the script, i.e. >>> >>> ``` >>> using Gadfly, Stan, Mamba, DataFrames >>> ``` >>> >>> After running a simulation, Mamba’s describe(::Mamba.Chains) could no >>> longer be found. >>> >>> I wonder if someone can point me in the right direction how best to solve >>> these kind of problems (for end users): >>> >>> 1. One way around it is to always qualify describe(), e.g. Mamba.describe(). >>> 2. Use isdefined(Main, :DataFrames) to upfront test for such a collision. >>> 3. Suggest to end users to import DataFrames and qualify e.g. >>> DataFrames.readtable(). >>> 4. ? >>> >>> Thanks and regards, >>> Rob J. Goedman >>> [email protected] >>> >>> >>> >>> >>> >> >
