Re: private functions in the core Octave distribution

[Jaroslav Hajek]

On Wed, Dec 2, 2009 at 10:23 AM, John W. Eaton <address@hidden> wrote:
> On  2-Dec-2009, Jaroslav Hajek wrote:
>
> | They prevent name clashes - for private functions, you don't need to
> | worry about inventing unique names. One can also use them to locally
> | override library functions. Effectively, they're like subfunctions
> | that are not limited to one m-file.
> |
> | What is the use of preventing the user from including them on purpose?
> | I just don't see why Octave should impose a restriction like that.
> | Surely you can work it around by moving the files or recompiling
> | Octave without this check, but why bother? Why should Octave decide
> | which files I can run?
>
> The scoping rules are set up so that private functions will find other
> functions in the same private directory.  But that is only true if the
> directory is a "private" directory, which means it is not listed in
> the path, but found implicitly, because it is called "private" and is
> a subdirectory of another directory that is in the path.  If you add
> the private directory to the path, then you break the scoping rules.
> For example, with the following functions
>
>  %% d1/f.m:
>  function f ()
>    'in f'
>    p ();
>
>  %% d1/private/p.m
>  function p ()
>    'in d1/private p'
>    q ();
>
>  %% d1/private/q.m
>  function q ()
>    'in d1/private q'
>
>  %% q.m:
>  function q ()
>    'in some other q'
>
> if I start Octave in the directory containing q.m and d1 and run
>
>  addpath d1
>  f
>
> I see the expected
>
>  ans = in f
>  ans = in d1/private p
>  ans = in d1/private q
>
> If I then add the private directory to the path and execute f again, I
> see the surprising
>
>  ans = in f
>  ans = in d1/private p
>  ans = in some other q
>
> I think it is worth preventing this kind of confusion.
>

OK, I see the problem. Still, I think there should be just a warning,
not an error.
This problem only happens because you have ./q.m and the "." directory
always stays at top of path. If the other q.m will be somewhere else
in the path and you prepend d1/private (which is the default), the
functions will still be able to correctly call each other. It only
works for one directory, but that is usually enough for debugging.

> You also can't call subfunctions directly.  Do you also want a
> mechanism to allow users to skip that scoping rule as well?

It would often help to be able to call a subfunction directly. Again,
for debugging purposes. I can live without that, though.

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