From maintainers-request at octave dot org Tue Apr 4 05:06:04 2006 Subject: Re: Beyond 2.9.5 From: David Bateman To: "John W. Eaton" CC: octave maintainers mailing list Date: Tue, 04 Apr 2006 12:01:26 +0200 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. For the changes for the octave_value class I'm not sure I see what we are winning. 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; 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); 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. Regards David > >Comments? > >jwe > > > > -- David Bateman David dot Bateman at motorola dot com 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