[Octave-bug-tracker] [bug #48693] classdef subsref method is not called with correct nargout value

[Mike Miller]

URL:
  <http://savannah.gnu.org/bugs/?48693>

                 Summary: classdef subsref method is not called with correct
nargout value
                 Project: GNU Octave
            Submitted by: mtmiller
            Submitted on: Wed 03 Aug 2016 03:02:56 PM PDT
                Category: Interpreter
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Matlab Compatibility
                  Status: None
             Assigned to: None
         Originator Name: 
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
                 Release: dev
        Operating System: Any

    _______________________________________________________

Details:

In a classdef handle class, the subsref method is supposed to be called with
`nargout` set to the number of values that the indexing argument addresses.

This works for old-style struct-based classes, but not for classdef classes.

Given the following constructor


classdef foo < handle
endclassdef


and the following simple definition of subsref


function varargout = subsref (x, idx)
  varargout = num2cell (zeros (size (idx(1).subs{1})));
endfunction


Then the following only returns a single value, even though the indexing
operation is over a range of 10 values, and nargout should be set accordingly
to capture 10 values:


>> x = foo;
>> x{1:10}
ans = 0
>> y = {x{1:10}}
y =
{
  [1,1] = 0
}



but, assigning to the right number of output values gets the correct output


[y{1:10}] = x{1:10}


If foo is changed to be a struct-based class with the following constructor,
but the subsref method is left exactly the same,


function y = foo ()
  y = class (struct (), "foo");
endfunction


then nargout is set correctly and the indexing examples work as expected.

This is a difference in how subsref is implemented in the octave_class vs
octave_classdef classes.




    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?48693>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/