[Top][All Lists]

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

Re: Robustness against accidental shadowing of 'core' functions

From: Andrew Janke
Subject: Re: Robustness against accidental shadowing of 'core' functions
Date: Wed, 5 Sep 2018 18:29:19 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

On 9/5/18 9:14 AM, Tasos Papastylianou wrote:
> My own opinion is that functions that are relied upon for 'core'
> functionality (such as 'glob' seemingly being used internally by 'pkg')
> should be called in a more carefully robust way (i.e. via 'builtin'), to
> prevent accidental breakage of core functionality in the event that an
> external package manages to shadow that function for whatever reason
> (good or bad).
> [...]
> Thoughts?

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.

Matlab seems like it might be going this way, too, with a +matlab namespace hierarchy.

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

On 9/5/18 4:57 PM, Kai Torben Ohlhus wrote:

> Honestly, we are talking about a
> non-Matlab function "glob", thus it is not a Matlab compatibility issue
> if it is not working.

The user has a program that works under Matlab, but fails under Octave. That sounds to me like the definition of a Matlab compatibility issue. The space of global identifiers which are available for user functions without interfering with the system's functioning is part of the language/platform's behavior.


reply via email to

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