[Top][All Lists]

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

Robustness against accidental shadowing of 'core' functions

From: Tasos Papastylianou
Subject: Robustness against accidental shadowing of 'core' functions
Date: Wed, 5 Sep 2018 13:14:04 +0000


We managed to spark an interesting conversation on stack overflow over this question:
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).

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

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.



reply via email to

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