Consider defining p5 methods as non-writable properties on window (in global mode)

[toolness]

I was just looking at #1314, where a user accidentally overrwrote p5's text function, and realized that one potential way to prevent this from happening is by defining p5's methods (in global mode) to be non-writable properties of the window object. Here's an example:

Object.defineProperty(window, 'text', {
   value: function() {
     console.log("TEXT WAS CALLED");
   },
  writable: false
});

text += "blah";

text();

In the above example, the assignment to text will silently fail, and the subsequent calling of text() will succeed.

Two alternatives that I think are possible:

1. Throw a helpful error if the value is overwritten, instead of failing silently.
2. Permit overwriting the value, but log a helpful warning telling the user that they just overwrote a core p5 method.

I guess alternative (2) might be best if we don't want to break backwards compatibility... Or we can just leave the current behavior as-is, of course.

[dhowe]

I've seen this problem with students, most commonly when they try to port a sketch from Processing (where this is not a problem) to p5js. So option 2 seems a good solution to me

[tafsiri]

A possible plus of option 1 is that the user might get a useful stack trace to help them find the error? For backwards compat either option might produce a lot of output unless they only trigger once per overwritten function.

[limzykenneth]

I feel it would be best to not limit what a user can and cannot do so +1 for solution 2 from me as well.

[tafsiri]

btw i should also add that I'd imagine option 1 could allow the assignment and then throw the error (which can be ignored) for debugging purposes. So its more like a warning but with a stacktrace. So maybe that is option 1.5 (assuming that it is actually possible)

[toolness]

Cool! Thanks for the feedback everyone.

@tafsiri, I am currently working on making errors more friendly in general, and part of that is going to involve using something like stacktrace.js to provide more helpful line numbers for users, as per #750--at least on non-minified builds of p5.

If more friendly line numbers were logged, would you be ok with option 2?

[tafsiri]

@toolness oh definitely, I think option 2 is good too (even without a line number). Was just brainstorming a bit on possible ways to help a user debug it (I even began to wonder if throwing and then immediately catching an error would help with getting a line number for printing out)—so def don't let me block you. But sounds like you are on the same page though!