On Tue, Sep 7, 2010 at 11:04 AM, CdeMills
<address@hidden> wrote:
The problem with something(dataframe(some_range)) is that we have (Jaroslav,
call so @dataframe/something, provided the first call returned a dataframe.
OTOH, is the chaining determined at run time ? I mean, before determining
which 'something' is called, the program has to determine the class of
df(some_range). So we could make things simpler if df(some_range) knows its
context, i.e. the function calling it. Is it possible in 3.2 -- will it be
possible in 3.4 ?
A problem with this sort of introspection is: How does an end user add support for conversion to a custom type? I believe one would have to customize @dataframe/subsref which would probably lead to a support challenges (e.g. for end users things like merging upstream changes may be difficult/troublesome, issues with debugging problems and troubleshooting on help@).
In the long run, it may be better to find an independent syntax that forces indexing to return a dataframe instead of a matrix and never even let bare () return a dataframe. You may even go so far as causing () indexing with incompatible column types raise an error instead of returning an indexed dataframe.
I think a clear separation of dataframe operations is going to be cleanest in the long run. There are a lot of choices for making dataframe do something different because [unlike () with matrices or {} with cell arrays or . with structs], subsetting a dataframe to obtain a dataframe does not require compatibility with anything else because dataframe is novel. How important is the future possibility of using @dataframe in the Matlab numerical environment? Things like df(1:2:end,:).dataframe or df.dataframe(1:2:end,:) should would work fine in either environment. I have no objection to things like:
myclass(df.dataframe(1:2:end,:))
myclass(df(1:2:end,:).dataframe)
The difference being that "dataframe" is being used as the struct key instead of "myclass".
--judd