[Octave-bug-tracker] [bug #58953] Error with 'end' in index expression with nested function calls

[John W. Eaton]

Follow-up Comment #31, bug #58953 (project octave):

The more I look at this, the more complicated it appears to be, which leads me
to think that I'm missing something that could make the implementation much
simpler.  For example, what happens for expressions like


obj{idx}(end)
obj.a.b(end)
obj.a{idx}.b(end)


etc.  Are these (conceptually) equivalent to


obj{idx}(feval('end',obj{idx},1,1))
obj.a.b(feval('end',obj.a.b,1,1))
obj.a{idx}.b(feval('end',obj.a{idx}.b,1,1))


?  If I understand correctly, evaluation of the partial expression for the
call to feval would result in one subsref call and the outer expression would
be another, with all arguments passed to that subsref evaluation.

I think that is all easy to fix now, but the thing that escapes me is how to
handle the following two cases differently:


obj.X(some_function(end))
obj.X(some_array(end))


I'm guessing there is some "natural" way of making this happen (especially if
TMW is basically admitting that this "feature" is an accident of their
implementation) but I'm not seeing it.

Given that any solution to this problem is likely to be disruptive, I think it
is best to abandon any attempt to fix it on stable and instead try to fix for
the next major release from the default branch.



    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?58953>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/