help-octave
[Top][All Lists]
Advanced

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

Some OOP questions


From: Judd Storrs
Subject: Some OOP questions
Date: Thu, 9 Feb 2012 11:05:00 -0500

Lately in my quest to simplify, clean my code, and improve
readability, I realized what I really need is just some way to attach
meta data to arrays and that I can achieve this using Octave's OOP.

The idea is to just add struct() interfaces to an octave array so that
meta data can be stored and retrieved. Ideally I would just subclass
the builtin types, but that doesn't work:

@wrapper/wrapper.m:
function w = wrapper(data)
  w.meta = struct();
  w = class(w, "wrapper", data);
endfunction

octave-3.6.1-rc0:1> w = wrapper(ones(10))
error: parents must be objects
error: called from:
error:   /home/storrsjm/src/epirecon/blah/@wrapper/wrapper.m at line 3, column 5
octave-3.6.1-rc0:1>

I didn't really expect this to work because @class stuff are really
struct games. It's too bad though, because something this
straightforward would really have been nice. I would just be
overriding and extending the default behavior where necessary. Not
knowing enough about the implementation, I don't know if it's possible
to add basic class support/emulation to the builtin types. So I got
something roughly working by (error checking removed):

@wrapper/wrapper.m:
function d = wrapper(data)
    d.data = data;
    d.meta = struct();
    d = class(d, "wrapper");
endfunction

@wrapper/subsasgn.m:
function w = subsasgn (w, s, v)
  switch (s(1).type)
    case "()"
      w.data = subsasgn (w.data, s, v);
    case "."
      w.meta = subsasgn (w.meta, s, v);
  endswitch
endfunction

@wrapper/subsref.m:
function b = subsref (w, s)
  switch (s(1).type)
    case "()"
      b = subsref(w.data, s);
    case "."
      b = subsref(w.meta, s);
  endswitch
endfunction

But now I'm going to end up with many, many, many copies of this:

@wrapper/foo.m:
function w = foo(w, varargin)
    w.data = foo(w.data, varargin{:});
endfunction

Is there a different way to handle that? Maybe something like a
generic "missing method" handler for the class?


--judd


reply via email to

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