Re: private functions in the core Octave distribution

[John W. Eaton]

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.

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

jwe