Re: Beyond 2.9.5

[David Bateman]

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                                address@hidden
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