Issues about this prototype #1
Description
This prototype demonstrates how to implement AbstractDataFrame
interface. The current implementation allows wrapping a data frame and possibly with additional data in the same struct. The idea came from this comment invenia/KeyedFrames.jl#19 (comment).
However, there are a number of unresolved caveats as documented below:
- I must define
Base.getproperty
(rather than forward) without running into trouble with theparent
function - I must define
Base.setproperty!
(rather than forward) to avoid method ambiguity. - I must define
Base.propertynames
withprivate
argument to make REPL completion work. - I must define several
Base.convert
functions - I must define
findrows
,findrow
,manipulate
, andSubDataFrame
functions.
Issue 4 troubles me the most. For the Base.convert
functions, they seems to be invoked during joins functions and eachcol
. And it calls for converting between a regular DataFrame
and my own type. If I have a type that contains more fields, there is no way to convert from a DataFrame
without filling in dummy information as evident in this line of code (required for passing the test):
Issue 5 is also also quite troublesome because I have to extend some internal DataFrames.jl
functions. I don't know why they do not take AbstractDataFrame
type as argument e.g.
https://github.com/JuliaData/DataFrames.jl/blob/fb4e184f3b3997da8680668fbf7fcc789811eb18/src/dataframerow/utils.jl#L301-L305