[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: overloaded function handles
From: |
Jaroslav Hajek |
Subject: |
Re: overloaded function handles |
Date: |
Mon, 27 Jul 2009 18:50:29 +0200 |
On Mon, Jul 27, 2009 at 5:41 PM, John W. Eaton<address@hidden> wrote:
> On 27-Jul-2009, John Swensen wrote:
>
> | I think patent number 6,857,118 is the more applicable one: "Function
> | values in computer programming languages having dynamic types and
> | overloading."
>
> Yes, sorry. I pasted the wrong number in.
>
> | That being said, I find it ridiculous that the ability
> | to overload a function by string name is actually patentable. There
> | has got to be gobs of languages that did the same thing before this
> | patent was issued, right?
>
> Yes, I agree that the claims for using '@' and 'feval' seem to go too
> far, and I don't see how they could hold up, but they could.
>
> However, if I understand it correctly, that's not the major point of
> this patent. Instead, the point is that you can create a function
> handle in one context, and then use that handle in another context to
> call a function, and the dispatch will be determined by the arguments
> given and information about which functions are available at the point
> where the funtion handle was created, not where it is used. Do you
> know of prior art for that? Is there a way to implement this feature
> in a way that does not use the method described in the patent? The
> language of claim 1 seems fairly broad.
>
> jwe
>
In that case, I find it completely ridiculous. The fact that the
handle must refer to multiple functions directly follows from the fact
that the name is overloaded and also refers to multiple functions -
the decision is just postponed. And it must be postponed, because at
the time of the creation of the handle there are no arguments
available.
The only possibly non-obvious part of this whole idea is, IMHO, the
decision that standard classes are looked up in advance, while user
classes are looked up on demand. This creates a good compromise in the
respective performance of the two actions.
In a certain way, the whole thing is similar to taking the pointer to
a virtual member function in C++ - the proper method will also be
determined at runtime, using the type of the called object. This can
be possibly seen as a prior art. Although it's about inheritance not
overloading, the principle is identical.
--
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz
- overloaded function handles, Jaroslav Hajek, 2009/07/23
- Re: overloaded function handles, Robert T. Short, 2009/07/27
- Re: overloaded function handles, John W. Eaton, 2009/07/27
- Re: overloaded function handles, John Swensen, 2009/07/27
- Re: overloaded function handles, John W. Eaton, 2009/07/27
- Re: overloaded function handles,
Jaroslav Hajek <=
- Re: overloaded function handles, Robert T. Short, 2009/07/27
- Re: overloaded function handles, Jaroslav Hajek, 2009/07/27
- Re: overloaded function handles, Robert T. Short, 2009/07/27
- Re: overloaded function handles, Jaroslav Hajek, 2009/07/27
- Re: overloaded function handles, Judd Storrs, 2009/07/28
- Re: overloaded function handles, Jaroslav Hajek, 2009/07/29
- Re: overloaded function handles, Judd Storrs, 2009/07/29
- Re: overloaded function handles, Judd Storrs, 2009/07/29
- Re: overloaded function handles, Jaroslav Hajek, 2009/07/29
- Re: overloaded function handles, Judd Storrs, 2009/07/29