[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: private functions in the core Octave distribution
From: |
Jaroslav Hajek |
Subject: |
Re: private functions in the core Octave distribution |
Date: |
Wed, 2 Dec 2009 11:09:09 +0100 |
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
- private functions in the core Octave distribution, John W. Eaton, 2009/12/01
- Re: private functions in the core Octave distribution, Søren Hauberg, 2009/12/01
- Re: private functions in the core Octave distribution, John W. Eaton, 2009/12/01
- Re: private functions in the core Octave distribution, Søren Hauberg, 2009/12/02
- Re: private functions in the core Octave distribution, John W. Eaton, 2009/12/02
- Re: private functions in the core Octave distribution, Jaroslav Hajek, 2009/12/02
- Re: private functions in the core Octave distribution, John W. Eaton, 2009/12/02
- Re: private functions in the core Octave distribution, Jaroslav Hajek, 2009/12/02
- Re: private functions in the core Octave distribution, John W. Eaton, 2009/12/02
- Re: private functions in the core Octave distribution,
Jaroslav Hajek <=
- Re: private functions in the core Octave distribution, John W. Eaton, 2009/12/02
- Re: private functions in the core Octave distribution, Jaroslav Hajek, 2009/12/02
- Re: private functions in the core Octave distribution, Søren Hauberg, 2009/12/02
- Re: private functions in the core Octave distribution, John W. Eaton, 2009/12/02
- Re: private functions in the core Octave distribution, Søren Hauberg, 2009/12/02