Codecov Report

All modified and coverable lines are covered by tests ✅

Thank you for implementing this !

It all looks good to me. I made some suggestions on the documentation.

About the quartet names, I agree that relying on the user to provide the right one is not sustainable.
Maybe one of these two solutions might work:

• create a tablequartetf4, that would just call tablequartetdata with the right names
• add an optional colnames field to the QuartetT{T} type. The default value from the constructor could be ["12_34","13_24","14_23"], but it could be specified when creating a new object. Then quartetdata_columnnames could use this field to get the correct names.

I think I like the second solution better. When we create a QuartetT{T}, we should know how we fill it exactly, so what should be the names. It is also more expandable: if we need to create an other type of Quartet object, we can choose the names directly. Note that we could also have an optional prefix field to the object, default to "CF", so that we would just need to call tablequartetdata on the object, and the correct names and prefix are used automatically.

The downside is that it requires a new field (I don't know if that is expensive ?), while the first solution might be easier to implement.

The second solution would be most robust indeed! The main issue, I think, is memory. The number of 4-taxon sets explodes quickly, for example with 1365 QuartetT{T} objects on only 15 taxa. If the vector or tuple ["12_34","13_24","14_23"] is stored independently 1365 times, that seems like a waste of memory.

Perhaps we could have QuartetTS{T,S} type with 2 parameters: T for the basic data type, and S might be a new type, for which we define a function columnnames(::S). For now, we would need one for concordance factors, and one for f4 statistics.

But this approach still requires some kind of memory to know that the object has type S, so I'm not sure it's worth the complication, compared to a simple function tablequartetf4 in your first solution.

Ah yes, good point about the waste of memory for vectors !

An other solution could be to create a new QuartetTVector structure, that would just be a vector of QuartetT, plus the colnames field (or an other parameter S). That way this information is only stored once for the whole vector. But that might be a breaking change (changing all the Vector{QuartetT{T}} to QuartetTVector objects), I'm not sure it would be worth the trouble.

Maybe tablequartetf4 is a good compromise then, unless we can think of something better.

The last commit uses strategy 1: with a new function tablequartetf4. I propose not exporting the generic tablequartetdata. quartetdata_columnnames was made more flexible.

I agree with exporting tablequartetf4 but not exporting the generic tablequartetdata.

I like this solution, it's simple and adds no memory burden. We'll just need to remember to possibly create a new fonction if we add a new time of quartet data structure in addition to CF and f4.

Thanks !