Re: overloaded function handles

[Jaroslav Hajek]

On Wed, Jul 29, 2009 at 11:18 AM, Judd Storrs<address@hidden> wrote:
> On Wed, Jul 29, 2009 at 3:40 AM, Jaroslav Hajek <address@hidden> wrote:
>>
>> 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.

OK, I tould why that is problematic. There's a very good reason why
the built-in classes should be pre-cached, and that reason is
performance of calling standard function via handles with standard
classes. You really want to avoid calling symbol_table::find_method at
each call.

> 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.

Absolutely not! If the handle refers to a locally visible function,
then it can't be overloaded - subfunctions and private functions are
preferred to class methods.

> 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.
>

I don't understand.

> 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.

I don't see how it could be done without a 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.

Yes, of course, that is the trick. Otherwise, the implementation would
be a good deal more complicated.

> 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.

But because type-overloaded functions are not local-scope, this is a
nonsense. Either the handle resolves to a local function, in which
case it won't be treated as overloaded (and is marked so), or it does
not, in which case it is marked as possibly overloaded, but then it's
scope-independent.

> 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.
>

OK, show me the code, then. I'm curious how you'd do it. I repeat,
local scope is only involved in determining *whether* the cache is
created, not in its creation. Therefore, it is irrelevant in what
scope it is done.

-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz