Re: File extensions in __list_functions__

[Søren Hauberg]

tir, 26 05 2009 kl. 09:52 -0400, skrev John W. Eaton:
> On 26-May-2009, Soren 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.

> Your message also reminds me that we currently have
> 
>   __list_functions__
>   __builtins__
>   __keywords__
> 
> How about being consistent and using
> 
>   __list_functions__
>   __list_built_in_functions__
>   __list_keywords__
> 
> ?

Seems reasonable.

> Also, why do we need a separate list of built-in functions?  Could we
> simply include the built-in function names in the output of
> __list_functions__?

Earlier when the user just typed 'help' (with no function name) a list
of functions would be printed to the screen. This list was sectioned
into 'built-in', 'm-files', etc. I think the reason for having a
function for listing built-in functions was to be able to produce this
list. But now this list has been removed, so I guess there is no need
for the function any more.

> Finally, is there currently a way to list all the visible function
> names with a single function call?  I think that could be useful thing
> to have.

Doesn't '__list_functions__' do this (except for built-in functions, but
that could be changed) ? It seems to include everything in the path.

> What about having a single function to list all the function names and
> keywords?  It could return a structure array with names and additional
> info about the functions.  For example, we could use the fields
> 
>   name = "for"
>   keyword = true
>   builtin = false
>   m = false
>   oct = false
>   mex = false
> 
> Or maybe there is a better way to do this?

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.

> 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.

Soren