Re: overloaded function handles

[Jaroslav Hajek]

On Tue, Jul 28, 2009 at 9:40 PM, Judd Storrs<address@hidden> wrote:
> What if we separate the use cases. Here's what I mean:
>
> 1) When you write an anonymous function it is clear which function is meant.
> No problem. That's the function you always get.
>

Yes, of course.

>
> 2) When you write @func and func is a function inside the file--that is the
> function you get always. Isn't that what you meant by putting in the same
> file?
>

Subfunction, or a private function, or even a class constructor (which
has higher priority than class methods). In all three cases the
function is unique, and no dispatch is done.

> 3) When you write @func and the function is not defined in the same file you
> get full function search including dynamic typing. This occurs at the time
> of use not creation.

Not really full, because you want to skip the current subfunctions and
private functions. Also, it's advantageous to cache lookups that have
already been done. Actually, this is very similar to what
symbol_table::fcn_info is doing; though the procedure is faster for a
handle.

> I think this would behave the way I expect in every case my feeble mind has
> been able to imagine. Unless someone plays games with temporarily toggling
> the path back and fourth. So except for those (what I consider fringe and
> pathologic) cases octave would do what you expect it to 99.9% of the time?

Yes, I think it works well. Or what are you trying to say? Maybe I'm confused...

> IANAL, but I don't think this approach can infringe because a list of
> functions and pointers to whatever is never ever created and stored with the
> handle at the time of creation.

Currently, there is a list involved; it lists the overloads for
standard classes.

> Am I missing something about how handles are expected to work?
>

No, probably not. I was a little confused about what you were trying
to say. Were you suggesting to change the implementation?

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