Example does not run as advised: probably need to get rid of weak typing in `ismethod` about dispatch.m HOT 4 CLOSED

Great! Thanks for confirming. I have to release a new version on the Matlab repository lists

from dispatch.m.

@bellomia Did #3 fix this issue?

from dispatch.m.

Yes as far as I'm concerned you can close it :)

from dispatch.m.

Do you mean the MathWorks File Exchange? I could not find a corresponding entry therein. Anyway I'm planning on trying a deep refactor to enable the "second" great pillar of Julia's approach to code reuse via multiple dispatch: I'm referring to the famous talk by Karpinski, in particular to the slide

The current implementation does not allow the user of a library which provides generic functions built through dispatch.m to add his own specialized methods, for that he has no access to the body of such wrappers. Don't get me wrong, it is already great for organizing runtime polymorphism in a self-contained Matlab project (much much better than the usual duck typing), but misses imo a great opportunity at enabling ergonomic code reuse.

So what I thought is to encapsulate dispatch() inside a suitable class so that a library would export an object instead of a generic function, as a wrapper of all the methods. Don't worry, I do not mean going full (nor even half) OOP style.

Something like:

>> % init the interface object, 
>> % there are no methods at first 
>> % (but there would be a one-shot constructor eventually, nevermind for now)
>> f = interface 

f = 

  interface with properties:

    method_list: {}

>> % Add a specialized implementation,
>> % by providing a lambda function 
>> % (or a handle of course) and the type signature...
>> f = f.add_method(@(x,y)(x+y),["numeric","numeric"])   

f = 

  interface with properties:

    method_list: {@(x,y)(x+y)  ["numeric"    "numeric"]}

>> h = f.activate % emit a function handle to allow calling the generic as in your implementation

h =

  function_handle with value:

    @(varargin)dispatch(self,varargin{:})

>> h(3,3) % test... and works!

ans =

     6
>>
>> % NOW, imagine this is what the library exports
>> % to the user, not just h(), but also the object f
>> % what we want now is to allow extending f, and
>> % eventually h(), of course....
>>
>> % So let's add another method
>> f = f.add_method(@sin,"numeric")                      

f = 

  interface with properties:

    method_list: {@(x,y)(x+y)  ["numeric"    "numeric"]  @sin  ["numeric"]}

>> h(pi/2) % If I don't "reload" it is not accessed by the handle (but this could make sense I guess...)
Error using interface/dispatch (line 59)
no method found

Error in interface>@(varargin)dispatch(self,varargin{:}) (line 34)
        handle = @(varargin) dispatch(self,varargin{:});
 
>> h = f.activate % So let's activate again the interface

h =

  function_handle with value:

    @(varargin)dispatch(self,varargin{:})

>> h(pi/2)   

ans =

     1
     
>> % hell yeah, successfully added another method,
>> % /dynamically/, which is the crucial requirement.

As you can see the class has just the role of allowing dynamic method extension (which happens automatically in Julia), and I believe should be sealed, to avoid dangerous mixing with OOP patterns: the user should just take the object from
the library and extend the methods (+reload) through the provided class-bound functionality.

All this is already implemented in my fork (in a seminal, rusty, stage for now), you can take a look and try it here. Please note that for now all the syntax is tentative and most probably I would change something, but the UI idea is already all there I think.

Tell me if you could be interested in such a huge modification (I understand if not, as it would drastically change the API). In that case we should move this discussion to a new issue and I could provide a targeting PR in a few days. Otherwise I would continuing exploring the idea on my own fork.

from dispatch.m.