Re: Really fix indexing in orderfields.m

[Jason Riedy]

And Jaroslav Hajek writes:
> But anyway I think that structs with more than, say, a dozen of fields
> are very rare, so I don't see optimizations here as necessary
> (currently getfield is m-file so it would loop anyway).

In Octave, definitely. If you're using structs as an imitation of R's
data frames, then having dozens of fields is not uncommon.  Or if you're
using it to slice a database[1] without knowing much about the data
structure.

> Instead of a struct with lots of fields, one may be better off using a
> list of keys and values separately, and use lookup + indexing (lookup
> now works with strings and does a binary search).

Well, yes, and you're also better off performance-wise writing a C++
extension. ;)

> > The surprise here is that t.("f1", "f2") returned *only* t.f1.
[...]
> I don't think this is supposed to work like that - it should give you
> a parse error. Do you have a counterexample?

That probably is a parse error, but put a cell array in there:
  t = struct ("foo", {1, 2}, "bar", {3, 4});
  nm = fieldnames (t);
  t.(nm)
will return the first field. It probably should issue an error,
or a warning if existing code assumes that behavior. So there's
a cellstr -> string conversion happening somewhere...

t.(nm{:}) errors out, as currently is appropriate.

Jason

Footnotes: 
[1]  I have a toy, *simple* DBI adapter for SQLite.  I need to rework
the matrix stuffing before it's ready for wide release, but it's at
  http://jriedy.users.sonic.net/cgi/jriedy/cgit/cgit.cgi/osdbi/
if you want a laugh.  I haven't tested it against a development version
of Octave yet.  Handy for throwing plot-generating data between Octave,
R, and other tools, although definitely not the right choice for most
uses.