octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: getstruct, setstruct, etc.


From: Andy Adler
Subject: Re: getstruct, setstruct, etc.
Date: Fri, 23 Jul 2004 16:43:09 -0400 (EDT)

On Fri, 23 Jul 2004, David Bateman wrote:
> This is a bit heavy, as every target would depend on a particular test
> in the configuration. Basically we know which versions of octave depreciated
> certain files and we can simplify all of the depreciated tests to one that
> just checks the version numbers.
>

If we use this approach with getstruct, setstruct, etc., then
I'll need to write two versions depending on when dynamic
field names were introduced.

I version with dyanamic field names would do:
    function s=mygetfield(s,varargin)
    % GETFIELD: access field members in a structure
    % example: given  ss(1,1).fd(1).b=5;
    %          getfield(ss,{1,1},'fd',{1},'b') => 5

    for idx= 1:nargin-1
       i=varargin{idx};
       if iscell(i)
          s= s( i{:} );
       else
          s= s.( i );
       end
    end

Could someone tell me when this feature started to be supported?
(I'm too lazy to check).

> This seems to me to be pretty generic and the minimum of additional
> work to maintain. The only issue is then where do the depreciated
> files live? For example sort.cc still lives in FIXES. But maybe each
> directory should have a depreciated directory where such files exist,
> or should we have a single directory in the root for depreciated files?
> Or maybe a combination of both?

I vote for a "deprecated" directory in each directory. It's clearer
that way. (Also, FIXES is a confusing name). I'll begin to do this
with the new getfield code.

Andy



reply via email to

[Prev in Thread] Current Thread [Next in Thread]