[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Beyond 2.9.5
From: |
John W. Eaton |
Subject: |
Re: Beyond 2.9.5 |
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