Re: problems to be fixed before next snapshot

[John W. Eaton]

On 23-Oct-2002, Paul Kienzle <address@hidden> wrote:

| So what does the array case look like when struct(1) is special?
| 
|       [nr,nc] = size(x);
|       if nr*nc != 1
|         for [val, key] = x, 
|           for r = 1:nr
|             for c = 1:nc
|               process val{r,c} key
|             end
|           end
|         end
|       else
|         for [val, key] = x,
|           process val key
|         end
|         endif

Hmm.  Currently, Octave can only do one-dimensional struct arrays,
though that should probably change soon.

| What does the non-array case look like when struct(1) isn't special?
| 
|       for [val, key] = x,
|         process val{1} key
|       end
| 
| The fact that the process code needs to be repeated in the array case with
| struct(1) special is bad, and IMHO outweighs the convenience gained in the
| common case.  Any other suggestions?

Right, I think it would be better to not have a special case here.

Should I change it back before the release?  If so, then you will have
some backward compatibility problems.

Note that in Matlab, if you write

  x(1).a = 1, x(2).a = 2, x.a

The result of x.a is a "comma-separated list" so you can do

  foo (x.a)

to pass the elements of the comma-separated list as separate arguments
to the function foo, but you can't write

  y = x.a

to capture the elements of the comma-separated list in a single
variable.

If Octave is changed to have multi-dimensional struct arrays, then
something like nd_struct.a would have to return a cell array, not a
simple list.  So there are going to be some more growing pains.  For
now, I think it would be more useful to make 2.1.37 available, so how
about if I leave it as a special case?  That way we are backward
compatible.  I'm planning to work on N-dimensional matrices next
anyway, so that will be a reasonable time to look at this again.

| If struct(1) is not special, I would like some way to conveniently deal
| with the change in semantics.  On possibility is a preprocessor for those
| who want to support multiple versions of octave and/or matlab with the same
| code base.  Another possibility is to use runtime tests, but I would prefer
| to avoid those.  If fact runtime tests won't work for varargin vs ...  
| A third possibility is to simply drop support for older versions of octave
| from octave-forge.
| 
| For a preprocessor I could do something such as
| 
|       % code %#if version test
|       code %#if version test
| 
| Then the preprocessor could add or remove the leading '%' depending on
| the version you specify when you run it.  

Building your own external preprocessor is always possible, but I'm
not really interested in making a preprocessor a part of Octave.  I
know that's not as convenient, but I think that adding a preprocessor
would add a lot of complexity that I'd rather avoid.

jwe