From maintainers-request at octave dot org Wed Apr 12 10:54:25 2006
Subject: Re: Beyond 2.9.5
From: "John W. Eaton" <jwe at bevo dot che dot wisc dot edu>
To: David dot Bateman at motorola dot com
Cc: octave maintainers mailing list <maintainers at octave dot org>
Date: Wed, 12 Apr 2006 11:54:14 -0400

On  4-Apr-2006, David Bateman wrote:

| If this is a 3.0 wishlist then you should include handle graphics and
| private directories and classes.
| 
| John W. Eaton wrote:
| 
| >I have the following plans for significant changes:
| >
| >  * Removal of built-in variables.  See the discussion on the
| >    maintainers list about DEFVARs.
| >
| >  * Changes to the octave_value class hierarchy.  For some info about
| >    this change, see the following messages
| >
| >      http://www.octave.org/mailing-lists/octave-maintainers/2004/437
| >      http://www.octave.org/mailing-lists/octave-maintainers/2004/443
| >      http://www.octave.org/mailing-lists/octave-maintainers/2005/960
| >      http://www.octave.org/mailing-lists/octave-maintainers/2005/961
| >      http://www.octave.org/mailing-lists/octave-maintainers/2005/962
| >
| >    I have a patch for this ready to go, but it will probably force a
| >    few changes in user-defined data types so I wanted some comments
| >    about it before committing the changes.
| >
| >  * Integrate Soren Hauberg's package system.
| >
| >  * Implement at least a simple form of the [x{:}] = fcn () syntax.
| >
| >  * Fix the behavior of anonymous functions as we have discussed
| >    recently.
| 
| I wonder if it might be better to add Soren's package manager (to allow
| octave-forge to be split up) and not much else and label a 2.9.x release
| as a testing release... 2.9.x is pretty stable as is.

Yes, we could do that, but I think I'd prefer to wait just a bit so we
can get some of the more painful transitions behind us all at once.  I
include the DEFVAR/DEFCONST changes and the changes in the
octave_value class hierarchy in this list.

| For the changes for the octave_value class I'm not sure I see what we
| are winning.

The change is not absolutely necessary (things work now) but it seems
like a somewhat cleaner way of doing things.  Given that the necessary
changes to user-defined types are relatively small, I think I'd like
to go ahead with this change.

| What I'd like to see is a consistent manner of creating and
| extracting an arbitrary type from an octave_value. That is, we have
| certain types that are in a privileged position like
| 
| NDArray m = arg.array_value ();
| octave_value retval;
| .....
| retval = m;

I would really prefer to keep this feature as I think it makes the
internals of Octave much easier to read and write.

| while an arbitrary type must do
| 
| MyType m = (const octave_my_type &)arg.get_rep()).mytype_value();
| octave_value retval;
| .....
| retval = new octave_my_type (m);

Do you see a better way of expressing this?  At the very least, we
could hide some of the ugliness behind some macros.

| getting rid of this distinction, it would then make sense to have the
| integer and sparse types external to the base octave, and probably all
| types and make the memory footprint of octave smaller.  The final brick
| in the same direction would be to have the mapper class treat the types
| generically.

Does it really make sense to remove all types from the core
interpreter?  Some will have to be loaded just to have Octave start up
do anything useful.

jwe