I don't understand why you would need to be able to create a function handle using @mycls.myfoo or mycls.myfoo.

If we fix the problem of looking up the method lazily, then won't code like your original example work properly when using just @myfoo in a scope where myfoo called with appropriate arguments finds the class method? In addition, doing lazy lookup will also improve compatibility.

I agree this is the wrong approach. I am working on a proper implementation that correctly parses invoking function handles using '@'. After that is complete (if that approach is acceptable) it should be quite easy to ask str2func to evaluate the code it got and return a function handle.

Thanks for taking your time to look at my ideas and the few lines of code I wrote!

For my needs the approach you suggested (that is closing this bug) is sufficient. However, I believe that in that case the error message needs to be changed.

With this class:

When calling

The response from the interpreter is:

This behavior suggests that it should be possible to create a method handle. If it is undesirable to create a method handle anywhere then the error message should be changed as well.

Because of this error message and the fact that someone had implemented parsing for creating a method handle within libinterp/octave-value/ov-fcn-handle.cc:make_fcn_handle() I will bring it up on the mailing list.

Regarding this item, I think the approach from bug #51599 is preferable, and this one to abandon:

1. It has limited use and works against the idea of OOP, to refer to a specific class method from OUTSIDE that class (comment #4), instead of Octave to find the appropriate `roots` method for the argument given.

2. It encourages "bad" programming style, with lots of references to keep consistent.

3. That it worked with Octave 4.0.3 seems to be more "accidental" than expected (this behavior is not documented).

4. It is not compatible with Matlab.

If you agree, we can stick with bug #51599 and close this item. Otherwise, I leave it open and you can discuss it on the mailing list.

I just was trying to get a handle to a method working somehow and I found that this way worked in 4.0.3. So I looked why it doesn't currently work and 'fixed' it. The function libinterp/octave-value/ov-fcn-handle.cc:make_fcn_handle already did the parsing. I just needed to make sure str2func actually ran make_fcn_handle instead of trying (and failing) to create an anonymous function.

I never argued that &quot;lazy evaluation&quot; should be a thing. I just wanted to mention that Matlab does in fact do just that.

I really want to create a function handle to class method, even if the creation happens only within the class scope. So should I bring it up on the mailing list?

I see, the lazy evaluation was already discussed in bug #31821 and discussed on the mailing list in 2009. So this behavior will not be added to Octave, I guess.

Regarding your patch. I find your patch useful in the scenario, that you want to control to use an class overloaded method:

On the other hand, I find this example kind of constructed and is there really a use case for it, instead of calling the class method directly? Or does Octave encourage programmers to adopt "ugly" indirection patterns? ^^

As far as I could tell Matlab resolves fcn_handles at runtime so if you have two classes with the same method name (let's call it 'foo') Matlab will let you:

and each time the proper method is called for each class.

With Octave the fcn_handles are resolved at assignment so the function you are pointing to must be visible to the interpreter when you create the handle. Matlab only checks if the handle makes sense when you use it.

Although in general creating a function handle fails using the @Class/Method syntax the
still worked as of Octave 4.0.3.

The fix to this seems to be a one-line check. Basically str2func assumes that is the string starts with '@' that means it is a anonymous function. Checking if the next non-whitespace symbol is '(' is can be used for disambiguation of the two cases.