Andy Ferris
Andy Ferris
It’s not just you - we need some version of this functionality. I was vaguely thinking `getproperties` would be generic. Some kind of `select` like JuliaDB would also be nice.
Cool! I actually think most of these are just filling out the obvious functions (which don't exist yet) of what you are calling the "PropertyAccessible" interface. What I'm getting at...
To be clear - my suggested path here is to create another package called *Properties.jl* and pad out exactly what the "PropertyAccessible" interface really means (with an eye to the...
Yes! That looks great. I kind-of feel a nice properties interface + a few container types and we've solved the struct-of-arrays vs arrays-of-struct problem pretty neatly, as well as giving...
There's an epic syntax hack here waiting to be exploited. @c42f **please** dissuade me. :smile: You get a single `column` of a `table` via `.` - e.g. `table.column`. What if...
So... how do we feel about `@Select` and the backend `GetProperties`. Should we close this issue, or would something additional be wanted?
@quinnj any advice on this one?
I see. Is it good practice to extend some of these methods and opt into common behaviour? Or is it preferable to let users use the `columns` function?
Yes, I think we should look at this. The dictionary-based tables have some checks now I believe.
This is an interesting request. Currently `Table` is simply an `AbstractArray`. We can try to `convert` things to the correct `NamedTuple` but going beyond this would change the philosophy a...