The private properties and methods in core.js are not actually private. True privacy can be a pain in JavaScript, but as part of the pseudo-privacy is it worth at least making them non-enumerable using Object.defineProperty()?
I've thought more about this one. I think it's not so important to us that these variables stay private, it's more that the "_" is a way of indicating that they are not public facing properties that a user needs to be concerned with. If the user wants to read or manipulate them, they are free to do so at their own risk.
Implementing the Object.defineProperty() for each of these will make the code somewhat less legible for beginners. I had to look up how Object.defineProperty() syntax works myself. Unless there's another reason I'm missing why letting these properties be enumerable is not a good idea, I would suggest we leave as is.
Anyone, thoughts?
I would agree with keeping it as is with _ syntax. The other option is to just make them vars inside the constructor function if they are only ever referenced inside there, although then they are not testable.
What is the use case for enumerating properties on the p5 object anyway?
@meiamsome they are used elsewhere so we can't just make vars, otherwise I agree that would be the best option.
I think that my making it non-enumerable means that it wouldn't show up if you were to iterate over the properties of the p5 object. maybe @vijithassar has more to add?
Correct, the main benefit of non-enumerable properties would be that they wouldn't be iterated over in a for-in loop, won't be included in Object.keys(), and so on. Makes sense to keep it as is if code readability is more important than clearing out artifacts from the public API.
This might be a strange suggestion, but would placing the _ methods under a private (or maybe internals) key in the object help make them less visible but still accessible?
would become
p5.prototype.internals.initializeInstanceVariables = function() {
We could even use Object.defineProperty() to make internals not enumerable (if we wanted) without having it all over the code.
I'm coming back to this and still feeling my earlier comment, and it seems there were no strong oppositions, so I am going to close this and prioritize other issues.
Most helpful comment
This might be a strange suggestion, but would placing the
_methods under aprivate(or maybeinternals) key in the object help make them less visible but still accessible?https://github.com/processing/p5.js/blob/bc108799df4a95f7dbbefd7fa5dfc6784379a2a2/src/core/core.js#L570
would become
We could even use
Object.defineProperty()to makeinternalsnot enumerable (if we wanted) without having it all over the code.