Re: Can we deprecate/remove extra arguments currently accepted by numel?

[John W. Eaton]

On 3/15/19 1:04 AM, Andrew Janke wrote:
> On 3/15/19 12:34 AM, John W. Eaton wrote:
> > Octave's numel function accepts extra arguments:
> >
> > octave:1> help numel
> > 'numel' is a built-in function from the file libinterp/corefcn/data.cc
> >
> >   -- numel (A)
> >   -- numel (A, IDX1, IDX2, ...)
> >       Return the number of elements in the object A.
>  > [...snip...]
> > Does Matlab still accept this usage?  It does not appear to be 
> > documented now.
>
> It may not be documented, but I believe that this calling form is still 
> implicitly used by the Matlab runtime in conjunction with overloaded 
> subsref and/or subsasgn for user-defined classes. (Remember when we were 
> discussing subref/sugsasgn semantics in IRC a week or so ago and you 
> were like, "WTF?"?) So, it's not just accepted, but required in some 
> cases, WRT classdef classes.

Yeah, I remember now.  Thanks for the info.  Could we check somehow 
whether this is still supported and whether it ultimately calls 
numArgumentsFromSubscript?  It would be nice to get rid of this calling 
form if it is undocumented and not needed.  But apparently you are 
saying it may be needed in some cases...

BTW, this is related to the overloaded virtual warnings since internally 
we have two different forms of numel in the octave_value class hierarchy 
and both forms are not always overloaded in derived classes.  So I was 
trying to decide whether we could get rid of the undocumented version, 
rename it to something other than numel, or just add using declarations 
like I have done now for a few other classes.

> > Is the function numArgumentsFromSubsctript somehow related to this 
> > (apparently obsolete) way of calling numel?
>
> I believe it is, but I'm not aware of any doco specifying how it works, 
> or how it interacts with numel().

Hmm.  OK.

jwe