Mon 03 Jul 2017 03:41:40 PM UTC, comment #13:
Other workarounds:
or
|
Mon 03 Jul 2017 03:36:35 PM UTC, comment #12:
So the issue I mentioned about "obj.method()" vs. "method(obj)" is probably related to the use of the "end" keyword in the expression. For example:
is not parsed correctly. While this works:
I can see it's been reported before: https://savannah.gnu.org/bugs/?50716
|
Fri 30 Jun 2017 09:17:49 AM UTC, comment #11:
Probably there are few problems here.
When using debugger, I have found that in Octave dev version,
varargin was empty, but in Matlab, it wasn't.
I have seen this problem also when trying to use "chebtest" from chebfun package http://www.chebfun.org.
|
Fri 30 Jun 2017 08:45:21 AM UTC, comment #10:
Don't know, I haven't had that problem in 4.2.1, it may be a regression in dev.
First I would verify it's indeed about "varargin". Based on the error you've shown in comment #7, I'm not so sure. Even if somehow "varargin" became empty, the call should still go through, and not give a mysterious "out of bound" error:
I think it has to do with the "myclass.static_function()" call itself, somehow not parsing correctly?
I have seen something similar with regards to "obj.method()" vs. "method(obj)" on regular class methods (which I previously mentioned in comment #5)..
|
Fri 30 Jun 2017 04:48:12 AM UTC, comment #9:
As I saw in comment #7, there is a problem that varargin is not transferred to a class function.
Should I open a new bug report for this?
|
Wed 28 Jun 2017 08:27:11 PM UTC, comment #8:
I pushed a new branch "octave" at:
https://github.com/amroamroamro/test_functions_scope/tree/octave
Basically I removed everything that doesn't work in Octave 4.2.1 as mentioned in previous comment (I also had to change some calls from "obj.method()" to "method(obj)" in some cases).
Result is that now all tests pass.
Simply diff the two branches to know what is currently not working in Octave:
https://github.com/amroamroamro/test_functions_scope/compare/octave
To test the dev version of Octave, you can try incrementally adding stuff which got recently fixed (like local functions defined in class files, or private-folder functions being called from class methods).
Hope this helps.
(file #41064)
|
Wed 28 Jun 2017 06:41:50 PM UTC, comment #7:
Checking on Win-7, using dev version
The problem is that in line 133 of myclass.m
function ret = static_function(varargin)
varargin is {}(0x0) but in the calling function it is 'local_function'
|
Sat 24 Jun 2017 01:30:29 PM UTC, comment #6:
I'm attaching a zip file of repo for posterity's sake.
(file #41038)
|
Sat 24 Jun 2017 01:17:08 PM UTC, comment #5:
Thanks John.
Inspired by the test case submitted by @gyom in #51276, I created a more extensive set of tests to cover more cases. The files can be found here:
https://github.com/amroamroamro/test_functions_scope
To run, cd into each directory one at a time, then run the scripts +myclass_test+ and +myclass_test_handles+ (you'll need to perform "clear -c"/"clear all" in between).
Here are the things covered in the tests:
- class defined in a self-contained file, versue class defined in @-folder (I'm referring to "classdef" style of classes)
- class inside +package folder and class inside nested packages +package/+subpackage (both cases of classes, self contained and @-folder)
- different kinds of functions: method function, nested function, static function, local function, private function
- in the case of @-folder class, test functions defined directly inside the class file or in an external separate m-file inside the folder
- testing both calling functions directly, or by returning a function handle
I ran the tests in MATLAB R2017a, no errors.
I then tried in Octave 4.2.1, here's a list of things that are apparently broken:
- defining +local_fuction+ inside a classdef file isn't supported.
- this syntax doesnt work: +@myclass.static_function+, instead we have to use: +@(varargin) myclass.static_function(varargin{:})+
- same thing when using an object: +@obj.method_function+ or +@obj.static_function+
- in some case calling methods as +obj.method_function()+ doesnt work right, instead we have to use +method_function(obj)+
- creating a function handle to a nested method is not supported +@nested_function+
- +private_function+ could not be called from functions defined inside the class file, only externally defined functions could access it (like +method2_function+ or +static2_function+)
- an exception to the previous point is when the class is defined inside a package, in which case even +method2_function+ and +static2_function+ cannot call +private_function+
- inconsistency when taking function handle to a member method: +@method2_function+ sometimes works, but +@method_function+ never does
Some of these bugs have been reported before, e.g #41723, #45351.
I ran the tests in Octave 4.2.1, I appreciate if someone could try it in dev...
|
Tue 20 Jun 2017 09:48:32 PM UTC, comment #4:
I checked in the following changeset:
http://hg.savannah.gnu.org/hgweb/octave/rev/97c3223c17a6
This could probably use a test file. Would someone like to add one and close this report?
|
Sat 24 Oct 2015 11:17:00 PM UTC, comment #3:
Just confirming this bug for me, and that Carnë's code (i.e. old-style OO code) works.
Carnë: out of curiosity; if you put your code under a namespace (e.g. +Foo), does your class still see the private method?
|
Tue 30 Jun 2015 04:42:11 PM UTC, comment #2:
Carnë:
I was talking about the new classdef-style OOP:
|
Tue 30 Jun 2015 04:33:42 PM UTC, comment #1:
I can't reproduce this for @class folders:
|
Tue 30 Jun 2015 02:05:32 PM UTC, original submission:
The following describes an issue related to path, packages and classes, and private functions:
where "bar.m" is a function that calls a private function "baz.m".
and
In Octave the following fails (while it works fine in MATLAB):
I had to explicitly add the private folder to the path for it to work:
Similarly, private functions inside @-class folders:
Trying to call "myfun.m" from class methods will generate a similar 'undefined function' error...
This was initially reported in #45410, but I'm creating a separate bug report for it.
|