Robustness against accidental shadowing of 'core' functions

[Tasos Papastylianou]

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

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.

Thoughts?

Tasos.