> That should be index(mydf).  I did get the small test case working, but I 
> still can't seem to use the same techniques to get my application working. 
>  I just don't understand how these method overrides are supposed to work. 
>  I originally thought that you just needed to have methods with the same 
> name and Julia would simply look at the name and the argument types to 
> determine the correct method to use.  But there is apparently more to it 
> since a previous suggestion was to do something like:
>
>    DataFrames.nrow(df::MyDataFrame) = ncol(df) > 0 ? 
> length(df.columns[1])::Int : 0
>
> I don't see why DataFrames should be involved at all.  I'm using 
> AbstractDataFrames as a super-type, but why would the DataFrames type have 
> to know about MyDataFrame? They are peers, so I don't see why DataFrames 
> would be special.

Note, DataFrames is not a type but the module.  The type is DataFrame.
It is customary (when applicable) to name the module (aka package) in
plural and the type in singular tense.  Now, generic functions carry
around with them the module in which they were first defined.  To extend
such a function with another method in another module you either have to
import it or fully qualify it (DataFrames.nrow).  If you don't do that
then you create a new generic function with the same name as the other
but not sharing any methods.  Also, this function will shadow the other
one in the current module.

However, as far as I understand “using DataFrames” +
“DataFrames.nrow(...)  =...” and "import DataFrames: nrow" + "nrow(...)
= ..." should be equivalent.  If that is indeed not the case, then it
sounds like a bug to me.  Do you have a self contained test-case?


> Actually, I'm kind of surprised that DataFrames' nrow is even implemented 
> on DataFrames and not AbstractDataFrames.  I would think that most of the 
> methods in dataframes.jl should be done on the AbstractDataFrame so that 
> anyone creating a subtype like I'm trying to do wouldn't have to 
> reimplement them all.  But that's another issue altogether.

If nrow is dependent on the implementation details of DataFrame then
that is the only way, otherwise it probably should be defined on 
AbstractDataFrame.

Reply via email to