Re: classdef support for octave

[Michael Goffioul]

(OK, not many reactions so far. I guess it's low priority...)

To answer myself, I think that the implementation should be
more tightly coupled to the symbol table code of octave. I'll
try to redesign the code that way (but it'll take some time as
it requires jumping into the intrinsics of symtab.[h|cc]). At first
sight, my first idea is to add a cls_info object to store class
specific informations, managing dispatching and inheritance
as well as class reloading.

I'll see what comes out of this. Any help is of course welcome.

Bye,
Michael.


On Wed, Sep 3, 2008 at 5:50 PM, Michael Goffioul
<address@hidden> wrote:
> Hi all,
>
> I've been thinking for a while about classdef support in octave,
> mainly because this oo-system seems to be closely linked
> to the graphics system. By looking at it at an early stage, I hope
> that it could be made quite compatible with the current graphics
> code, such that both can co-exist and interact nicely.
>
> Yesterday, I decided to give it a try by laying down what I had
> more or less in mind (before forgetting it...). You can see this
> embryonic result in attachment. Without going too much into
> details, the idea is to build the system upon a simple object
> type (a set of slots) and to provide programmatic interfaces on
> top of it. This allows to easily make objects accessible from the
> interpreter. The implementation is partially inspired by LISP and
> the MOP. The code in attachment only shows the very beginning
> of the bootstrap code, but I'm focusing on the framework to see
> what are the pro's and con's of the design choices I made. This
> stuff can completely change in the future.
>
> This work is a long-term issue and I only plan to work on it from
> time to time (when I get bored doing something else...). The code
> has the form of an oct-file (normally it should compile fine) and I
> plan to keep this code outside of octave for now (which also means
> no syntactic sugar in the interpreter).
>
> Now come the questions. Do you find this interesting? Do you think
> the code in attachment might be a way to go? Who's willing to
> join?
>
> The only things you can do with the code currently are:
>
>  init_classdef
>  c = get_class ('meta.class')
>  % any other meta.class property should be OK.
>  c.Properties
>  % does nothing as some code is missing
>  c.fromName ('meta.property')
>
> Bye,
> Michael.
>