classdef support for octave

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

classdef support for octave

Michael Goffioul
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.

classdef.h.gz (3K) Download Attachment
classdef.cc.gz (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: classdef support for octave

Michael Goffioul
I forgot to attach one file.

Michael.


On Wed, Sep 3, 2008 at 5:50 PM, Michael Goffioul
<[hidden email]> 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.
>

init_classdef.m (156 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: classdef support for octave

Michael Goffioul
In reply to this post by 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
<[hidden email]> 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.
>
Reply | Threaded
Open this post in threaded view
|

Re: classdef support for octave

David Bateman-3
Michael Goffioul wrote:

> (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.
>
>  
No comments not because of lack of interest but because my minds on
other things.. I think it would be great to have classdef support for
3.2 if its relatively easy to implement as you imply.

D.


--
David Bateman                                [hidden email]
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph)
Parc Les Algorithmes, Commune de St Aubin    +33 6 72 01 06 33 (Mob)
91193 Gif-Sur-Yvette FRANCE                  +33 1 69 35 77 01 (Fax)

The information contained in this communication has been classified as:

[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary

Reply | Threaded
Open this post in threaded view
|

Re: classdef support for octave

Michael Goffioul
On Thu, Sep 4, 2008 at 11:31 AM, David Bateman
<[hidden email]> wrote:
> No comments not because of lack of interest but because my minds on other
> things.. I think it would be great to have classdef support for 3.2 if its
> relatively easy to implement as you imply.

I didn't imply that :-)

A complete implementation requires work on the internal data representation
and MOP, work on the parser for the syntactic sugar (classdef parsing,
?-syntax for class access, @-syntax for overloaded method call in the
parent classes...), work on the tree evaluator (for package scope handling).
So 3.2 is not a realistic target. For now, I'm mainly thinking about the
first part.

Michael.
Reply | Threaded
Open this post in threaded view
|

Re: classdef support for octave

John W. Eaton-6
On  4-Sep-2008, Michael Goffioul wrote:

| On Thu, Sep 4, 2008 at 11:31 AM, David Bateman
| <[hidden email]> wrote:
| > No comments not because of lack of interest but because my minds on other
| > things.. I think it would be great to have classdef support for 3.2 if its
| > relatively easy to implement as you imply.
|
| I didn't imply that :-)

I'm also busy this week with other projects.

| A complete implementation requires work on the internal data representation
| and MOP,

MOP?

| work on the parser for the syntactic sugar (classdef parsing,
| ?-syntax for class access, @-syntax for overloaded method call in the
| parent classes...), work on the tree evaluator (for package scope handling).

I could probably help with this if you can explain the syntax, or
point to a more or less complete description of it.

| So 3.2 is not a realistic target.

I agree.  I think this should not be added until after 3.2.

jwe
Reply | Threaded
Open this post in threaded view
|

Re: classdef support for octave

John W. Eaton-6
In reply to this post by Michael Goffioul
On  4-Sep-2008, Michael Goffioul wrote:

| (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.

How does dispatch work for the classdef classes?  Where does it fit
in with the current order for symbol lookups?

jwe
Reply | Threaded
Open this post in threaded view
|

Re: classdef support for octave

Michael Goffioul
In reply to this post by John W. Eaton-6
On Thu, Sep 4, 2008 at 4:10 PM, John W. Eaton <[hidden email]> wrote:
> I'm also busy this week with other projects.

No problem. This is a long-term issue.

> | A complete implementation requires work on the internal data representation
> | and MOP,
>
> MOP?

Meta-Object Protocol.

> | work on the parser for the syntactic sugar (classdef parsing,
> | ?-syntax for class access, @-syntax for overloaded method call in the
> | parent classes...), work on the tree evaluator (for package scope handling).
>
> I could probably help with this if you can explain the syntax, or
> point to a more or less complete description of it.

I can only point you to the Mathworks documentation, which is the
source I'm using (I'm stuck with Matlab 2006b, which does not
support this feature):

http://www.mathworks.com/access/helpdesk/help/techdoc/index.html?/access/helpdesk/help/techdoc/matlab_oop/ug_intropage.html

Michael.
Reply | Threaded
Open this post in threaded view
|

Re: classdef support for octave

Michael Goffioul
In reply to this post by John W. Eaton-6
On Thu, Sep 4, 2008 at 4:12 PM, John W. Eaton <[hidden email]> wrote:
> How does dispatch work for the classdef classes?  Where does it fit
> in with the current order for symbol lookups?

Dispatching and symbol lookup works more or less the same
as the old OO system, based on the arguments and the inferior
relationship between them. But there are things that make it
slightly more complex:
- access modifiers: public/protected/private
- methods can be in separate file or in class definition file or
in both (declared in the classdef file and implemented in a
separate file)
- package scoping and package import list

For now, I think that I'll continue to develop the draft code I sent
yesterday; with some modifications, I'm confident it could be
hooked up in the current symbol table code without too much
effort. Basically, wherever you look for a class constructor or
class method, you could first check with the new OO code,
then with the old OO code. However, now it's easier for me to
keep the code separate.

Michael.
Reply | Threaded
Open this post in threaded view
|

Re: classdef support for octave

Michael Goffioul
On Thu, Sep 4, 2008 at 4:36 PM, Michael Goffioul
<[hidden email]> wrote:
> For now, I think that I'll continue to develop the draft code I sent
> yesterday; with some modifications, I'm confident it could be
> hooked up in the current symbol table code without too much
> effort. Basically, wherever you look for a class constructor or
> class method, you could first check with the new OO code,
> then with the old OO code. However, now it's easier for me to
> keep the code separate.

For people that wants to have a look at the current code this
weekend, here it is. For now, I consolidated the framework
and add the bootstrap code for 3 meta classes (class, property
and method).

Comments are welcome.

Michael.

classdef.tgz (10K) Download Attachment