[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Some OOP questions

From: CdeMills
Subject: Re: Some OOP questions
Date: Thu, 9 Feb 2012 12:33:50 -0800 (PST)

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.meta = struct(...) ;
>     image = process(image);
> but then you have to rewrite your functions to use 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.



View this message in context:
Sent from the Octave - General mailing list archive at

reply via email to

[Prev in Thread] Current Thread [Next in Thread]