Ok. Let me try again. I'm sorry for these long emails, but I feel like what I'm trying to say isn't being understood. The way I see it the reality is that octave can either infringe on Matlab's patent, not implement overloaded function handles or find some way to work around the claims. We all know about the patent so infringing at this point is willful infringement which triples damages.
I'm trying to work around the claims because I would like to be able to use overloaded function handles. I think I see a hole in the patent that relates to this statement in the Detailed Description:
"ii. Path and scope are not considered when applying a function handle. The
work of initial function lookup is performed when the function handle
is constructed. This does not need to be done each time the function
handle is applied. Indeed it
cannot be done when applying the handle, because scope at the point of
application is not the same as the scope at the point the function
handle was constructed."
What I am saying is that "it
cannot be done when applying the handle" is false in practice for the specific case of overloaded functions in the Matlab language if the path does not change between creation and use of the handle.
I don't see how full compatibility can be achieved without infringing
the patent, so I'm trying to propose a compromise. What I'm trying for
is a loss of strange corners of compatibility in exchange for
compatibility with what I suspect are the overwhelming number of cases.
Of course, it would be possible to write code that behaves differently
in
Matlab and octave by exploiting the differences, but I'm unsure how
likely it is that such code would
be encountered in the wild?
My questions are whether the discrepancy in implementation (i.e.
overloaded functions created in context2 instead of context1) makes any
real world difference to actual useful code? And whether anyone else
agrees that it avoids the claims of the patent.
--judd
Shifting path lookup to the first (and *only* the first use) instead of at the time of creation will not significantly impact performance. i.e. the following analogous codes:
handle = populate_function_list__danger_slow(handle, context1) ;
# Evaluation -- in the style of Matlab
apply_overloaded_handle(handle,context2,args) ;
IMHO this implementation infringes because it is exactly what is claimed--the function list is created at the same time in the same scope that the handle is created. What I am suggesting is that instead
# Creation -- not in the style of Matlab
handle = create_new_handle_with_empty_function_list() ;
# Evaluation -- not in the style of Matlab with cacheing
if handle_has_empty_function_list(handle)
handle = populate_function_list_danger_slow(handle, context2) ;
end
apply_overloaded_handle(handle,context2,args) ;
Since the handle will have an empty list only the first time it is
used, the slow cache creation only happens once in both cases. The "if"
test at each use should be negligable compared to the path search esp.
in a complied language like C++. I'm NOT suggesting that we do this:
# Creation -- not in the style of Matlab
handle = create_new_handle() ;
# Evaluation -- not in the style of Matlab but very slow
handle = populate_function_list_danger_slow(handle, context2) ;
apply_overloaded_handle(handle,context2,args) ;