beddalumia / matlab-multiple-dispatch

Providing julia-inspired multimethods to MATLAB, as suitable function objects. [proof of concept!]

Linguist stats

Main activity within the Quantum condensed matter Physics LAB @ SISSA

   

   

PhD projects at CM @ SISSA [i.e. project reproducibility vaults]

   

Some other things that I am very proud of...

   

matlab-multiple-dispatch's Issues

Sudden inexplicable under estimation of coverage for `multimethod.interface` [should be 100%, measured 68%]

Codecov reports a quite low coverage of the interface class, specifically complaining about all error handling statements not being reached:

But, from the CI log we have:

Which pretty much shows that those lines are covered, specifically in: https://github.com/bellomia/matlab-multiple-dispatch/blob/b8ba9dd7714fbcc98f45e17d293d1ed05873e38c/.test/test_error_handling.m#L8-L14

So what's the matter with those lines? Why does Codecov miss them in the report?

Also note that in just one of the previous commits (bc586fc) the report measured a 100% coverage in interface.m, which should be the correct assessment. So why it stopped working?

Design a way to make easy to extend the method table to a user that has no access to the original dispatch implementation

The current seminal implementation on master is very rusty, of course.
Having the method table defined just as a cell array makes for a trivial
implementation, but not very safe especially as it requires the user to
build a valid table himself. Also if user A builds a library making use
of our multiple-dispatch API and user B wants to import the generic and
then extend it with his own custom methods, he would need access to the
original code by A.
This is more or less what you have in languages with static overloading
but Julia does neatly better, allowing powerful and pervasive reuse and
composability.

I wonder if we should build a method_table / methods / interface / class
that encapsulates a safe (set of) constructor(s) for the table, the
generic function handle and the dispatch function itself. Then the class
could be imported by both user A and user B, so to allow A to define his
generic fA object and specialized methods in his own library and B to
extend such object (not the class!) with new method table entries, i.e.
his own specializations. This would effectively allow easy inter-library
composability. Also, B could either extend the actual object provided by
A or just his own copy, which would arguably be safer.

I can't foresee now all the possible pitfalls, I guess we could just try…