Why does the signature of my method change at runtime?

I have a class (made in App Designer) with a method that takes two arguments:

function updateSpeed(app, block)

end

This function is used inside a callback that is used in an event listener listening for a block's 'PostOutputs':

listener = add_exec_event_listener(block_name, 'PostOutputs', ...
    @(block,event) updateSpeed(app,block));

With this code I get a 'Too many input arguments' error. However, the code runs fine if I change it to:

listener = add_exec_event_listener(block_name, 'PostOutputs', ...
    @(block,event) updateSpeed(app));

If I change the method to only take one argument, and only give it one, I get the 'Too many input arguments' again. It seems that for some reason the method signature is changed to only accept one argument. I have also tried changing the method name to something obscure so I know there's not more than one method of that name.

I need to access the 'block' parameter inside 'updateSpeed', so this doesn't work. I know class methods can have more than one parameter from this page:

https://www.mathworks.com/help/matlab/matlab_oop/specifying-methods-and-functions.html

Why is this happening?

[Tommy]

Would you be able to provide your entire class?

[Matthew Drummond-Stoyles]

Sure, here it is. Not going to include the referenced model because it depends on a whole bunch of other stuff. But the error should be the same for any model

[Tommy]

Just after taking a quick look, I'll point out that you can either reference your function with

@(block, event) app.updateSpeed(block)

or

@(block, event) updateSpeed(app, block)

but not

@(block, event) app.updateSpeed(app, block)

In your question, you used the second syntax, but in the file you uploaded, you use the third. Just to verify, do you still get an error if you change it to the first or second syntax?

(edit) copied to an answer, at least for now

[Ameer Hamza]

Yes, Tommy's analysis is correct. The way you wrote it in the question caused confusion. I suggest Tommy add this as an answer so that It can be accepted and be useful for anyone else coming to this thread.

Answer 1

[Tommy]

You can either reference your function with

@(block, event) app.updateSpeed(block)

or

@(block, event) updateSpeed(app, block)

but not

@(block, event) app.updateSpeed(app, block)

In your question, you used the second syntax, but in the file you uploaded, you use the third. Do you still get an error if you change it to the first or second syntax?

[Matthew Drummond-Stoyles]

I am not sure, because the app has an earlier problem now. I had been using a workspace variable for 'app' as a temp workaround to this problem, and now that my computer restarted, the workspace variable is gone and it seems the variable does not get re-assigned each time the app runs, contrary to what I thought. Could the problem have been that I was accessing the method of an older 'app' instance?

[Matthew Drummond-Stoyles]

Also, why does the third syntax not work? Is the 'app' parameter implicit when using the first syntax? I am used to Java where everything is cut and dried and the method is exactly as it's defined.

Thanks for your help

[Tommy]

To be honest, I am not too familiar with Simulink. It seems like this 'StartFcn' needs to be set to a MATLAB expression, and I guess this expression is evaluated in the base workspace? Which is possibly why you were able to solve the problem by having an instance of your object in the base workspace?

You can always save a new instance of your app by requesting output when you start the app:

app = vehicle_model;

If what I said above is true, that does not seem like a good way to solve your problem, but again I'm a bit out of my element here...

What I can tell you is that the first argument in any non-static method of a class always references an instance of the object. It is similar to self in Python or this in Java, except unlike Java, it must be explicit in the function signature. This is arguably more cut and dried from a perspective within the method, because you know exactly what variables you can work with. Admittedly it can be confusing when calling the method. The way I see it is, when you call

app.updateSpeed(block)

MATLAB finds the method of the object app which is named updateSpeed, and it passes the object app as well as the input you supplied, block. This is similar to Python. Using

updateSpeed(app, block)

instead is equally valid and matches the function signature exactly. MATLAB again needs the app object to find the method. The third syntax,

app.updateSpeed(app, block)

could not possibly also be valid, if the first two are valid, because MATLAB wouldn't have a clue whether you mean to pass app as the function's second argument (in addition to it's first argument, which, sure, would be silly) or if you mean to skip it.

Sorry I can't be of more help here...

[Steven Lord]

The syntax

app.updateSpeed(app, block)

is under most circumstances equivalent to

updateSpeed(app, app, block)

See the "Dot Notation vs. Function Notation" section on this documentation page if you're interested in the details of when they aren't equivalent.

FYI, Tommy, when you wrote "What I can tell you is that the first argument in any non-static method of a class always references an instance of the object." that is not necessarily true. When you call a non-Static method of a class at least one input argument for that method must be an instance of that class, but it need not be the first.

See for example the plus method of the DocPolynom example class defined on this documentation page. If you set a breakpoint inside the plus method you can see that both the uses of + below call that method even though in the second case it's the second input, not the first, that isa DocPolynom. But asking for y = 2 + 3 wouldn't invoke DocPolynom's plus method because neither 2 nor 3 isa DocPolynom.

p1 = DocPolynom([1 2 1])
p2 = p1 + 1
p3 = 2 + p2

[Tommy]

Ah! Thank you very much for correcting that - I reread the note here and realized it doesn't say anything about the order!

[Matthew Drummond-Stoyles]

You are correct about the 'StartFcn' requiring an expression and it being evaluated in the base workspace. That was the topic of my other question and it seems the only workaround is to use a global variable for the app instance. Your suggestion about requesting output would also work but I am not sure if that would work if I ran the app through the app designer window or when creating an executable.