rewrite of structs - advice sought

[John W. Eaton]

On 22-Jun-2010, Jaroslav Hajek wrote:

| 1. general opinions about this? Is this a worthy goal for Octave? So
| far it had been mostly fun, now the hard work (debugging) begins, so
| I'd like to know if I should abandon the effort in time.
| 
| 2. naming: I chose octave_map and octave_scalar_map, so that
| octave_map and Octave_map only differ in capitalization. Since
| Octave_map should eventually go away, this almost-nameclash seemed OK
| to me, but I'm open to objections.

Is there a less radical set of changes that could be made that would
improve performance but leave the existing interface while not having
two internal implementations?  I guess I don't see why you need to
completely replace the old interface with something new.  Instead,
wouldn't it be possible to change the internals of Octave_map to be
more efficient and add whatever new methods make sense or are needed
for the new internal representation?  Rather than allowing conversion
to/from a new octave_{scalar,}map and the old Octave_map classes, you
would only have to convert the new internal layout when needed by the
old interface functions.

Use of any functions that require conversion and that are likely to be
inefficient could be documented as being slow, deprecated, and perhaps
eventually removed.

If I had it to do over again, I would have used the name octave_map
instead of Octave_map, so I certainly don't object to that change...

jwe