[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Robustness against accidental shadowing of 'core' functions

From: Mike Miller
Subject: Re: Robustness against accidental shadowing of 'core' functions
Date: Thu, 6 Sep 2018 12:07:09 -0700
User-agent: Mutt/1.10.1 (2018-07-13)

On Wed, Sep 05, 2018 at 18:29:19 -0400, Andrew Janke wrote:
> Namespaces seem like a natural fit here, at least for some of the problem.
> If you were designing Octave from scratch now, and wanted to make Matlab
> compatibility a priority, you could have an "octave" namespace that
> contained all the functions supplied by Octave that are not present in
> Matlab. That way you only have one global name that's subject to collision,
> and one that users are unlikely to use themselves. Similarly, functions for
> Octave's internal use that shouldn't be called by user code could go in
> "octave.internal". It would be "future-proof", too: you wouldn't have to
> worry about future versions of Matlab introducing a "glob()" function with
> incompatible semantics. Perhaps future Octave-specific global functions and
> classes should go in a namespace, to avoid this issue.

We do that to some extent. For example, Matlab function names are not
allowed to start with underscores. Many private or internal Octave
functions start with double underscores. Also Matlab-provided functions
seem to avoid underscores in general, while many Octave-only functions
do include underscores.

I think that standard C library function names should be kept as is. For
example, the functions getgrent, getpwent, glob, and unlink are all
simple wrappers for the corresponding C functions. If namespaced, maybe
a "libc" namespace would be appropriate.

Another strategy for future-proofing might be to provide the full
implementation of a function, let's say glob, as a compiled function
__glob__. The the glob name could be a convenience wrapper for the user.
All Octave functions can safely call the underlying __glob__ function
with less danger of being shadowed.

> Seems like it would be a lot of work (and code uglification) to try to
> defend against this shadowing everywhere, though, with either namespaces or
> "builtin".


> The user has a program that works under Matlab, but fails under Octave.

Not really. In this particular case, the error is happening when the
user tries to call the Octave pkg command after loading another
third-party module into their global namespace. If they don't use the
pkg command, there is no failure.


Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]