If you want to propose an alternative implementation, go ahead. I'm
fairly sure that the idea of dropping the cache would result in
inferior performance, but maybe you can manage something I just don't
see.
Ack, no! I'm not suggesting we drop the cache! I'm just suggesting that one way to avoid the patent would be to delay cache creation for type-based overload until the handle is used the first time. For non-type-based overload, the dispatch is fully resolvable at creation but IMHO that doesn't infringe.
You're first reaction should be that if you delay cache creation until first use it would result in an incorrect cache because it's created in the wrong scope. What suggesting is that limitations of the Matlab language help out here. For type-based dispatch I don't think there is any difference as long as the file search path doesn't change between creation and use.
If the handle is anonymous or a subfunction or
in the same file it can be fully resolved at creation. In all other cases the
cache is built at first use only. The cache is used subsequently without performance
penalty.
The reality of the Matlab language is that it does not permit you to create type-overloaded subfunctions or type-overloaded anonymous functions. You must use @class directories which requires the file path search mechanism. A correct type-based overload cache can be built from any scope unless the path is changed between handle creation and first use.
Essentially the patent only covers the case
that a handle represents a cache of type-overloaded functions containing multiple implementations and is also created from the
same scope that the handle is created.
By fully resolving some functions at creation and not creating the cache at creation for all other cases the claims do not apply. And it's possible to get very very close to what Matlab does. Deferring cache creation until first use shouldn't cause a performance hit because the cache has to be built once sometime anyway.