[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Changing the way dispatch works for built-in functions
From: |
Julien Bect |
Subject: |
Re: Changing the way dispatch works for built-in functions |
Date: |
Tue, 13 Dec 2016 07:39:54 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.4.0 |
Le 13/12/2016 à 00:40, John W. Eaton a écrit :
While looking at this bug report
https://savannah.gnu.org/bugs/?49794
I started thinking about how to better handle dispatch for built-in
functions. Currently, built-in functions are found last. The search
is performed in symbol_table::fcn_info::fcn_info_rep::xfind:
http://hg.savannah.gnu.org/hgweb/octave/file/9b096bffc10d/libinterp/corefcn/symtab.cc#l647
As things are now, if you create a .m file function with the same name
as a built-in function, the .m file function will always override the
built-in function. But, if we were to install built-in functions in
the map from class name to function (the same one that is currently
only used for user-defined classes) then we could limit the damage
someone could do by installing a plain old function with the same name
as a built-in. For example, if we installed the current built-in svd
function in the class map for double and single classes, then the
built-in svd function would be found when svd is called with a double
or single argument. The only way for a user to accidentally override
the built-in version would be to create a function @double/svd
@single/svd.
Hi John,
The change that you propose also improves Matlab compatibility.
I have made a quick test on R2016a: creating svd in an ordinary
directory doesn't override the core svd function for single and double
argument ; creating the same file a a directory named "@double" does.
@++
Julien