adopt getobs/numobs?

[CarloLucibello]

Would this package be willing to adopt numobs and getobs from MLUtils.jl?
I think that they are better suited to this package than to the heavier MLUtils.jl.

In practice the content of this file
https://github.com/JuliaML/MLUtils.jl/blob/main/src/observation.jl
should be moved here, except maybe for AbstractDataContainer.

It contains the definitions of getobs, getobs!, numobs along with a few lines of implementations for Base's basic types.

[ablaom]

An interesting idea. I was hoping LearnAPI.jl could be kept lightweight (zero dependencies, only method stubs or very basic fallbacks) so a separate package might be preferable (Observations.jl?). I think the proposed code inclusion needs Tables.jl and some trait package right?

It's true that, by default, algorithms implementing LearnAPI.jl are assumed to consume data implementing the getobs/numobs interface (or will do in 0.2.0), but they can also opt out. And if they do introduce bespoke data objects that must implement getobs/numobs, they typically don't need access to the names to do so, but just overload Base.length and Base.index. So we'd be forcing most LearnAPI client packages to import code they don't actually need, right?

Is there a compelling reason for not having a separate package?

[ablaom]

In any case, it would be great for these methods to find a final home before the release of LearnAPI 0.2.0 (first "official" release).

[CarloLucibello]

I think the proposed code inclusion needs Tables.jl and some trait package right?

just Tables.jl, we don't use traits AFAIK

Edit: there is also SimpleTraits.jl dependence

Is there a compelling reason for not having a separate package?

not really, just trying to avoid having another package to maintain. But I agree that having a standalone package would be better.