Re: File extensions in __list_functions__

[John W. Eaton]

On 26-May-2009, Søren Hauberg wrote:

| tir, 26 05 2009 kl. 09:52 -0400, skrev John W. Eaton:
| > On 26-May-2009, Søren Hauberg wrote:
| > 
| > | When generating documentation caches for 'lookfor' we use the
| > | '__list_functions__' function (defined in 'src/help.cc'), which returns
| > | a list of functions in a given directory. Currently, the returned list
| > | of functions includes extensions, i.e. you get list elements like
| > | "foo.m" and "bar.oct". This is breaking the cache generation in 'pkg'.
| > | 
| > | My questions is, should '__list_functions__' be changed such that
| > | extensions are not returned, or should functions calling
| > | '__list_functions__' remove the extensions themselves?
| > 
| > Are the extensions actually used anywhere?
| 
| Not that I know of. In the cache generation they actually cause bugs.
| 
| > Would it be
| > useful to be able to distinguish among .m, .oct, and .mex files?
| 
| I use the function (mostly as part of the package manager) to get a list
| of functions. Here it doesn't matter how the function is actually
| implemented. But I guess it might be useful, though I can't come up with
| any good examples...
| 
| > It seems odd that __list_funtions__ returns a list of function names
| > without extensions, but __list_functions__ (DIR) returns a list with
| > extensions.
| 
| I agree. I think the function should never return extensions.

OK.  Currently, __list_functions__ (DIR) is just calling 

  string_vector fl = load_path::files (dir);

so it gets a list of all files, not just .m, .oct, and .mex files.
Maybe we need a

  load_path::fcn_names (DIR)

function that returns the names of the functions defined in a
particular directory, regardless of whether DIR is actually in the
load path.  This function would just be in the load_path class becuase
it seems to be a related function.

I'll add this function and fix __list_functions__ (DIR) unless you
object.

| Yeah, I guess this would be a nice feature, but I can't really come up
| with a good use-case for it. IMHO, we shouldn't design an API for this
| unless we actually have a reason for having it.

OK.  It can wait.

| > It might also be good to have a data structure that would allow us to
| > easily produce diagnostics about functions that have multiple
| > definitions.
| 
| I guess that could be helpful for debugging, though I don't think I've
| ever needed this.

I think it might be helpful for Octave to provide this kind of warning
by default to help avoid confusion when a package overloads some
existing function.  Perhaps it could be limited to overloading of core
functions?

jwe