From maintainers-request at octave dot org Thu Jul 22 16:25:17 2004
Subject: Re: getstruct, setstruct, etc.
From: Paul Kienzle <pkienzle at users dot sourceforge dot net>
To: octave maintainers mailing list <maintainers at octave dot org>
Date: Thu, 22 Jul 2004 17:24:21 -0400


On Jul 22, 2004, at 4:03 PM, Andy Adler wrote:

>> On Jul 21, 2004, at 4:21 PM, Andy Adler wrote:
>>
>>> QUESTION:
>>> Is anyone feel strongly about changing the octave-forge functions
>>> to be closer to Matlab?
>>
>> I would prefer it, but getfield/setfield are used elsewhere in
>> octave-forge,
>> so make sure they don't break.
>>
>> You should probably keep the old versions around but rename them
>> to make it easier for those who depend on the existing  behaviour in
>> their private scripts.
>
> The only parts of octave-forge that depend on this behaviour are:
>
> ./main/miscellaneous/read_options.m
> ./main/optim/minimize.m
> ./main/struct/test_struct.m:     # this is obvious
> ./main/vrml/                     # many functions
>
> I can modify this. Any ideas on what to rename them to?

Since the existing functions allow get/set on multiple fields
simultaneously, I suggest getfields and setfields.

Etienne, any comments?

> Here is my proposed fix. They're written as *.m files, but that
> should be OK since this syntax is deprecated anyway.

Having to use eval is kind of ugly.  It seems like there should
be a recursive solution like:

	getfield(s):
		return s
          getfield(s,idx,field,idx,...):
		return getfield(s(idx).(field)(idx),...)

and

	setfield(s,v):
		s = v
		return s
	setfield(s,idx,field,idx,...,v):
		s(idx).(field)(idx) = setfield(s(idx).(field)(idx),...,v)
		return s

I don't know that it would be any faster though.  And setfield
will fail if field does not already exist.  So eval it is.

- Paul