How to configure Editor when working on class methods so that I can jump to implementation?

I'm working on a small project with only a handful of classes, but there's still enough methods to not keep a complete list in my head for everything. I cannot find a way to efficiently work.

To clarify, assume the following situation:

• I'm working on a file some_methodA.m, which implements method some_methodA() of class A. The path to this file is projectdir/@classA/some_methodA.m
• I want to invoke some_methodB() from class B, which is in projectdir/@classB/some_methodB.m
• I start typing, inside some_methodA.m: b_object.some_methodB(), but then I realize I forgot which arguments some_methodB takes.
• I right-click on some_methodB() and choose "Open some_methodB()" to check (since there's no auto-completion in the editor...!?), but I get an error message saying that some_methodB.m does not exists and if I want to create it.

Note that all the paths I mention are on the MATLAB path.

The root cause of the problem is that the MATLAB editor doesn't know that b_object is an instance of classB, so it doesn't know where to find some_methodB. In my opinion, it should at least suggest that there is a matching function somewhere on my path and suggest opening that one. Yet, it doesn't.

My current way of "working" now is to keep the class definition files open in the editor and, if I'm looking for something, I right-click on the tab for the corresponding, choose "Change current folder to ...", and then open the file that implements the method I'm interested in. Which is totally ridiculous and inefficient.

I cannot imagine working like this on a bigger project, yet I know there are bigger projects being done in MATLAB. So, what am I missing? How can I configure the Editor or path variable or whatever so I can work more efficient?

Answer 1

[Sean de Wolski]

I usually work in debug mode, either from calling something at the command line or by running a unit test.

You're working on classA.someMethod, but a break point on line 1.

Run the test that calls classA.someMethod or run it directly at command line. Stop in debug mode. You now can see the state of the object as it is when someMethod is called and have access to all private/protected properties or methods. By being in an executed state, MATLAB now knows that objectB is classB.

I'll typically: enter debug mode, write a few lines of code, evaluate it with highlight-run selection to make sure it does what I want, quite debug mode, advance break point, rerun test.

[Ludo Visser]

You're kidding, right? Is the MATLAB language so broken that the only way to resolve symbols is to actually run it and then develop in debug mode?

I was hoping that I accidentally misconfigured something or just missed some preference setting. But if this is the official (staff) suggested way of working, I think I better just quit this project...

Sorry for the cynical response, but this is a joke.

[Sean de Wolski]

This is the way I do it (I am not in development) and the approach is one that I've found to work for me. It is not an official recommendation from of my corporate overlords.

MATLAB is a dynamically typed language so it is not possible for it to know everything a priori.

[Ludo Visser]

Sorry Sean, I didn't mean to attack you personally. The "staff" tag implies you're MW staff, and my frustration is aimed at MW, not you.

I actually tried your suggestion to code in debug mode, but I don't think it's a workable solution, because you're then forced to work on only one place. I can't switch to a another file since the editor will complain that it can't save the file in debug mode (since the default preference is to save files when you leave its editor window). If I turn the autosave option off, I still cannot edit another file, since the current scope is of the method where the debugger is stopped.

Python is also dynamically typed and any half-decent Python editor can do code completion and symbol lookup without having to execute the code. Hence my conclusion that the MATLAB language is fundamentally flawed.

If you have any influence on MW - please make them reconsider the language design. I'm willing to sacrifice backwards compatibility if that gives me a decent language and IDE in return...!

[Sean de Wolski]

No offense taken! I have nowhere near as much influence as you do as a customer calling in to tech support and mentioning Python capabilities. When I want to complain, in order to get things done, I usually try to find a customer who agrees with me. That's one of the reasons why I partake in these discussions because I can now cite this thread.

While I can't talk about the future, if you look at 18a, there is new infrastructure for adding function signatures for code complete/suggest especially in regards to the live editor.

https://www.mathworks.com/help/releases/R2018a/matlab/matlab_prog/customize-code-suggestions-and-completions.html

This is on top of the 17b automated/contextual hints in live editor:

https://www.mathworks.com/help/releases/R2018a/matlab/release-notes.html

Support for functions and debugging support came in 18a to live editor but classes aren't supported at this time.

This should at least let you know they're actively working on improving this space, you may be able to extrapolate, and feedback to dev is welcome!

Also, instead of working in debug mode, you can instantiate the object you want to reference, this may be easier if you're switching between files/sections often.

>>b_object = b  % at command line or highlight/evaluate

Now in class

b_object.<tab> % should work 
b_object.someMethod % Right click after highlighting someMethod, "Open" should work.

[Rik]

That auto-completion with function hints is really a long-awaited functionality. Now it would be cool to have that inside your function, instead of in a separate file.

My suggestion would be something like the block below (borrowing the example from the link). This way, this .m file will remain compatible with previous releases.

% myFunc  Example function
% This function is called with any of these syntaxes:
%
%   myFunc(in1, in2) accepts 2 required arguments. 
%   myFunc(in1, in2, in3) also accepts an optional 3rd argument. 
%   myFunc(___, NAME, VALUE) accepts one or more of the following name-value pair 
%       arguments. This syntax can be used in any of the previous syntaxes.
%           * 'NAME1' with logical value
%           * 'NAME2' with 'Default', 'Choice1', or 'Choice2'

blank_line_hidden_by_forum_layout
%{
%#functionSignature
{
  "_schemaVersion": "1.0.0",
  "myFunc":
  {
     "inputs":
     [
        {"name":"in1", "kind":"required", "type":["numeric"], "purpose":"ID of item"},
        {"name":"in2", "kind":"required", "type":["numeric"], "purpose":"# Items"},
        {"name":"in3", "kind":"ordered", "type":["numeric"], "purpose":"Input Value"},
        {"name":"Name1", "kind":"namevalue", "type":["logical","scalar"],"purpose":"Option"},
        {"name":"Name2", "kind":"namevalue", "type":["char", "choices={'Default','Choice1','Choice2'}"]}
     ]
  }
}
%}
function myFunc(reqA,reqB,varargin)
    % Initialize default values
    NV1 = true;
    NV2 = 'Default';
    posA = [];

      if nargin > 3
          if rem(nargin,2)
              posA = varargin{1};
              V = varargin(2:end);
          else
              V = varargin;
          end
          for n = 1:2:size(V,2)
              switch V{n}
                  case 'Name1'
                      NV1 = V{n+1};
                  case 'Name2'
                      NV2 = V{n+1}
                  otherwise
                      error('Error.')
              end
          end
      end
  end

[Ludo Visser]

It's of course silly to have to write JSON just to get autocompletion to work. Actually, beyond silly. Things like Javadoc and Doxygen exist for this.

Sean's last suggestion, to instantiate an object with the same name in the command line and then use autocompletion in the editor is kind of a useful workaround. It's silly that the editor has access to the scope of the interpreter (and I didn't know it had), but in this case it is useful. At least a workable approach; thanks Sean.

[Rik]

It's not just silly to have to write JSON, it also doesn't seem to work outside of the live editor (and doesn't seem to load the multiple syntaxes correctly).

I'll be posting a question about this when my frustration has become a bit less.

[Rik]

I posted my question.

Answer 2

[Lucademicus]

I'm not sure if I correctly interpret your question, but I think I noticed the following behavior.

When I type

instanceOfClassA.someMethod('someinput')

and I want to see the code of someMethod, I usually right click and choose

"open instanceOfClassA.someMethod"

In that case it would say that the method does not exist. Really annoying, as this works with normal functions.

But when I type

someMethod(instanceOfClassA,'someinput')

and if I right click on someMethod and "open someMethod", it does bring me to the correct code.