Enhancement: result for loop()

[mkrasuski]

Nature of issue?

• [ ] Found a bug
• [x] Existing feature enhancement
• [ ] New feature request

Most appropriate sub-area of p5.js?

• [ ] Color
• [x] Core/Environment/Rendering
• [ ] Data
• [ ] Events
• [ ] Image
• [ ] IO
• [ ] Math
• [ ] Typography
• [ ] Utilities
• [ ] WebGL
• [ ] Other (specify if possible)

Which platform were you using when you encountered this?

• [ ] Mobile/Tablet (touch devices)
• [ ] Desktop/Laptop
• [ ] Others (specify if possible)

Details about the bug:

• p5.js version:
• Web browser and version:
• Operating System:
• Steps to reproduce this:

Feature enhancement details:

Would be useful to have result for loop() as result of the previous state: true for enabled looping and false for stopped. For example:

if (loop()) noLoop();

would switch looping on/off...

[mebble]

I'd like to have a go at this. So you're saying loop would modify the loop state (setting it to true) and return the previous loop state value, right?

[Spongman]

i think it'd rather have loop() and noLoop() be chainable, and have an explicit method for reading the current state. the above doesn't leave a way to query the current state without changing it, beyond var s = loop(loop()); which seems overly complicated and probably has unintended side-effects within the library (like rendering an extra frame, etc...).

ideally, we'd have something along the lines of:

loop():boolean;
loop(value:boolean):p5;

which would match the other getter/setter pairs in the API, but this would break existing code and processing alignment.

[mebble]

Yeah not being able to read the state without changing it is a bad idea. An explicit method would be very useful, or perhaps a global variable? p5 already has keyIsPressed etc, so a variable like isLooping would be consistent with the API.

Also could you explain what you mean by making loop() and noLoop() chainable?

[limzykenneth]

Changing the behaviour of loop() and noLoop() will probably break a lot of existing code as they are used pretty often so it probably will not be considered, a global variable however I don't see why it won't be possible to have that. Overall I would like to have a way to query if the sketch is looping or not as well, otherwise I will need to have keep track on my own with a toggling variable when I need it.

[mebble]

I'm new to p5 but I'd love to work on this. The basic idea is something like the following code snippet

// In /src/core/structure.js
p5.prototype.loop = function() {
  this._loop = true;
  this._setProperty('isLooping', true);  // the new variable
  this._draw();
};

[Spongman]

yeah, i like the isLooping property.

btw: chainable just means that the method returns this

[limzykenneth]

@mebble Do go ahead with your PR, if you can include tests and documentation then it will help greatly with getting it merge. If you need help with those, checkout the developer docs or ask anyone here.

[lmccart]

We don't currently have getters for a lot of p5 settings set by the user. For example there's no getFill() getStroke() isSmoothed() etc. Since the state is known at the start (looping), couldn't the user easily keep a boolean variable to track for themselves whether the looping has been toggled?

[limzykenneth]

That is how I currently keep track of the looping state. It does add a bit of extra code and I need to make sure to toggle whenever the looping state change in the code. I guess it is a nice to have at the very least but if it doesn't align with the intent of the library (as other states are also not readable) I'm not that attached to the idea as well.

[Zalastax]

I think you should just document the internal variables and if they have names that start with _ rename them. Write that the variable is read-only! An alternative if you want to be more fancy is to use a real getter. Making loop() return a boolean is more complicated than you need and it's also not great to force users to manage their own version of the data (it might go stale and it just makes their code more complicated imo).

[lmccart]

internal variables attached to p5 with underscore are named that way to decrease the chance there will be a conflict of names as all p5 properties and functions are bound to the window in global mode. we can talk about whether we'd like to move to getters across the library, but I think that is a broader issue since there are a number of setting methods that don't currently have them. so let's open a new issue for that if it is a question people want to consider.

[Qianqianye]

Close this because it's completed!