Re: Some OOP questions

[CdeMills]

Judd Storrs-2 wrote
> 
> 
> I guess I think of dataframe as more like R's data.frame for solving
> the problem where you have heterogeneous data that's structured
> somewhat as rows and columns.
> 
> What I'm dealing with are 3D and 4D complex/real images. I just want
> to tack some metadata on them to reduce the amount of
> housekeeping/boilerplate code that gets spread everywhere (things like
> real world positions, dimensions, sample identifiers, timestamps).
> I've usually done it two ways:
> 
>     [image,info] = process(image,info,args);
> 
> But too often you start out implementing a processing function (or you
> get it from someone else) that doesn't use meta data and you start a
> function like this:
> 
>     image = process(image);
> 
> and you get a few calls deep and you want to extend things but you
> need to peek at some metadata and then you have to go update all the
> function interfaces to add the meta data (and don't even think about
> passing function handles around). So at some point I started doing it
> this way:
> 
>     image.data = ... ;
>     image.meta = struct(...) ;
>     image = process(image);
> 
> but then you have to rewrite your functions to use image.data instead
> of image (really not too huge a problem, but still annoying). It's
> just so tempting to somehow make use of the unused "." indexing on the
> numeric types somehow, because that syntax currently does absolutely
> nothing. And the more I thought about it, I kept thinking of different
> ways to use meta data.
> 
> In my mind the two approaches are (1) add it as a core functionality
> for all numeric types or (2) fix OOP subclassing of builtin types so a
> subclass can easily add it. I'm leaning towards (2) as a better
> approach. I think it can be mocked up using @class style OOP. Anyway,
> I think it's a little different from dataframe.
> 
> 
> --judd
> 
> 
> 

Dataframes are indeed conceived to store heterogeneous data which occur in
tabular form, yet a third dim is supported. 

In your case, you could think the reverse way: define an image class and add
all the required meta. This way, you would have a familly of functions whose
argument is an image. All the needed info will percolate through the call
tree, no need to complicate the interface.

Regards

Pascal 

--
View this message in context: 
http://octave.1599824.n4.nabble.com/Some-OOP-questions-tp4373321p4374281.html
Sent from the Octave - General mailing list archive at Nabble.com.