Re: problems to be fixed before next snapshot

[Paul Kienzle]

On Tue, Oct 22, 2002 at 10:33:40PM -0500, John W. Eaton wrote:
> On 22-Oct-2002, Paul Kienzle <address@hidden> wrote:
> 
> | I don't know if it is a problem, but the new behaviour of 
> |     for [key,val] = struct
> | is a bit disturbing to old code (or is it [val,key] --- I never remember).
> | 
> | val is now a cell array whereas old code expected it to be a octave value.
> | 
> | I understand why it has changed (how else can you process key,val pairs
> | when struct is an array?), but I would rather that it didn't make
> | the common case more awkward.  I don't have anything better to suggest
> | in its place.
> 
> OK, this prompted me to find a couple more bugs in structs.  I've just
> checked in some fixes to CVS.  Now we have
> 
>   octave:1> x(1).a = 1; x.a
>   ans = 1
>   octave:2> for [val, key] = x, val, key, end
>   val = 1
>   key = a
>   octave:3> x(2).a = 2; x.a
>   ans =
>   (
>     [1] = 1
>     [2] = 2
>   )
>   octave:4> for [val, key] = x, val, key, end
>   val =
>   (
>     [1] = 1
>     [2] = 2
>   )
>   key = a
> 
> This makes the single-element structure array special.  I'm not sure
> that's the best choice, but it is backward compatible and somewhat
> convenient.
> 
> The only trouble is writing code that must work when the number of
> elements in the struct array is sometimes one and sometimes more than
> one...

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

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?

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.  

Suggestions?