help-octave
[Top][All Lists]
Advanced

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

Re: Robustness against accidental shadowing of 'core' functions


From: Kai Torben Ohlhus
Subject: Re: Robustness against accidental shadowing of 'core' functions
Date: Wed, 5 Sep 2018 22:57:20 +0200

On Wed, Sep 5, 2018 at 3:14 PM Tasos Papastylianou <address@hidden> wrote:
Hi,

We managed to spark an interesting conversation on stack overflow over this question: https://stackoverflow.com/q/52174614/4183191
I thought it might be more fruitful to continue this in the mailing list.

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

There is just one spot where "glob" is used inside "pkg" to tell if a file exists [1].  If the developers of "Lightspeed" adapted their "glob" interface to Octave's, the "pkg" function might run perfectly with it.

I agree that ultimately the package developer is largely responsible for not breaking core functionality by inappropriate shadowing, but this does not negate the argument for built-in robustness against such errors.

The examples of accidental function shadowing are even worse, sometimes trivial, sometimes subtile.  See some examples from our mailing-list [2-4].  Just look for "shadow" and you'll find some.  That is the price to pay for this feature, like all languages offer features, that have to be used with care (bad memory access [off by one errors] in C, MS Office macro malware, ...).  You cannot simply defeat against/imagine as developer all of the mistakes of bad intentions of human beings.
 
The example in the stackoverflow question is a nice one demonstrating this point, since the developer of Lightspeed was not negligent or acting in bad faith; they simply built a matlab package which works as intended on matlab, but happens to break octave in the manner stated above.

If the package is so prominent, file a bug report [5] for Octave compatibility or fork the project (MIT licence) if the developers are not responsive (4 open bugs, last commit 10 months ago, 17 commits in total).

The problem described on stackoverflow is prettily easy solved: Do the Octave stuff first (pkg install...), then load the non-Octave stuff.
 
I hesitate to call this a bug, since, after all, we're talking about a package that was not written specifically with octave in mind. At the same time, however, it is entirely conceivable that had 'pkg' used the builtin 'glob' rather than whichever happened to be path-available at the time, then the package would work as expected.

Thoughts?

Tasos.

Sure this is no bug, it's a feature to defend against packages, that don't care about Octave ;-)  *joke* Honestly, we are talking about a non-Matlab function "glob", thus it is not a Matlab compatibility issue if it is not working.

Kai.

[1]: http://hg.savannah.gnu.org/hgweb/octave/file/144820478378/scripts/pkg/pkg.m#l416
[2]: http://octave.1599824.n4.nabble.com/command-log-2-give-value-as-500-tp4686644p4686648.html
[3]: http://octave.1599824.n4.nabble.com/question-about-a-mysterious-error-tp4686531p4686532.html
[4]: http://octave.1599824.n4.nabble.com/Plot-function-not-working-tp4679313p4679320.html
[5]: https://github.com/tminka/lightspeed/issues


reply via email to

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