New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
toolness opened this Issue Mar 22, 2016 · 6 comments

Comments

Projects
None yet
4 participants
@toolness
Member

toolness commented Mar 22, 2016

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

This comment has been minimized.

Show comment
Hide comment
@dhowe

dhowe Mar 22, 2016

Contributor

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

Contributor

dhowe commented Mar 22, 2016

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

This comment has been minimized.

Show comment
Hide comment
@tafsiri

tafsiri Mar 22, 2016

Contributor

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.

Contributor

tafsiri commented Mar 22, 2016

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

This comment has been minimized.

Show comment
Hide comment
@limzykenneth

limzykenneth Mar 22, 2016

Contributor

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.

Contributor

limzykenneth commented Mar 22, 2016

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

This comment has been minimized.

Show comment
Hide comment
@tafsiri

tafsiri Mar 22, 2016

Contributor

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)

Contributor

tafsiri commented Mar 22, 2016

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

This comment has been minimized.

Show comment
Hide comment
@toolness

toolness Mar 22, 2016

Member

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?

Member

toolness commented Mar 22, 2016

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

This comment has been minimized.

Show comment
Hide comment
@tafsiri

tafsiri Mar 23, 2016

Contributor

@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!

Contributor

tafsiri commented Mar 23, 2016

@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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment