octave/matlab differences for methods(<class>)

[cbm755]

In Symbolic, I have a @logical dir which adds a single method (isAlways) to the logical class.

• In Matlab, methods('logical') gives all sorts of stuff abs, all, amd, any, etc and including my isAlways method.
• In Octave, methods('logical') gives just isAlways.

Maybe this is an upstream Octave bug.

But even in the Matlab case, should doctest then call doctest on all of these methods? Even those not defined in this 'project'? This is good for a user, but for package maintainer, I want to doctest my local stuff...

[catch22]

That's a good question. I believe the intuitive thing might be to just test those methods that are explicitly documented in the class definition (after all, this is doctest 😄).

At some point we might then want to add an explicit directive that tells doctest to test the overriding method with the overridden method's doctests (but let's do this when the problem arises).

[oheim]

https://savannah.gnu.org/bugs/?func=detailitem&item_id=44390

However, it makes sense to only test methods that actually are overridden in the subclass and contain new test cases.

[cbm755]

I don't think we need this for a point release. I'll drop the milestone

[cbm755]

There are two slightly different things being discussed here:

1. class C is a subclass of P. The discussion is whether doctest C should test methods defined only in P.
2. a "local class directory" that "monkey-patches" new methods onto an existing class. This was my original doctest logical example. There I feel doctest logical might do something different depending on whether there is a local @logical directory or not. Or maybe doctest logical might have different behaviour than doctest @logical.

[catch22]

Thanks for clarifying.

Intuitively, I would expect that only doctests defined explicitly in files the local @P / @logical directories are tested.

[apjanke]

IMHO this methods() behavior is definitely an upstream Octave bug. If it's supposed to be Matlab M-code compatible, methods() should return all the methods that are dispatchable on an object or type, regardless of whether they were inherited. Should probably code doctest with the expectation that this behavior may change in the future, and if you want compatibility across Octave versions you'll need a compatibility shim or a different source of the methods list. Maybe .MethodsList from meta.class?

[cbm755]

How is that supposed to work? Is it only for classdef?

>> m = meta.class.fromName(sym)
error: wrong type argument 'class'
error: fromName: CLASS_NAME must be a string
>> m = meta.class.fromName('sym')
m = [](0x0)

[apjanke]

Aw, darn. Yeah, I guess it's only for classdef or traditional user-defined classes, not built-in types. I don't know if this is a deviation from Matlab behavior.

[cbm755]

sym is a user-defined class... Am I doing it right?

[apjanke]

You're doing it right. Looks like Octave’s meta.class only supports new-style classdef (“MCOS”) classes, not old-style “@ directory” classes. I’d call that a bug in Octave. But it does mean that meta.class won’t be usable here, at least for the time being.

Maybe doctest is stuck searching the path and doing its own class definition parsing if it wants to be thorough, and also not have the methods() behavior of including inherited methods.