Increasing access
Better parameter validation makes p5.js more beginner-friendly. When a new user calls ambientLight(), directionalLight(), pointLight(), spotLight(), lightFalloff(), specularColor(), or noLights() with incorrect arguments, they currently get cryptic runtime errors or silent failures. Adding friendly error messages through p5._friendlyError()
helps users understand what went wrong and how to fix it - directly supporting p5.js's mission of making creative coding accessible to everyone, including those new to programming.
Most appropriate sub-area of p5.js?
Feature enhancement details
Seven WebGL light functions in src/webgl/light.js have commented-out parameter validation (// p5._validateParameters(...)) and TODO comments requesting parameter checks (//@TODO: check parameters number).
Affected functions:
ambientLight (line 176) - commented-out validationspecularColor (line 407) - commented-out validationdirectionalLight (line 587) - commented-out validation + @todopointLight (line 813) - commented-out validation + @todolightFalloff (line 1069) - commented-out validationspotLight (line 1289) - commented-out validationnoLights (line 1352) - commented-out validation
Additionally, the renderer-level implementations in Renderer3D.prototype.lightFalloffand Renderer3D.prototype.spotLight use console.warn() instead of p5._friendlyError(), which is inconsistent with the Friendly Error System.
Proposed changes:
- Replace commented-out
p5._validateParameters() with argument count/type checks using p5._friendlyError()
- Convert renderer-level
console.warn() calls to p5._friendlyError()
- Add unit tests for all validation cases
- Preserve chainability (return
this) on validation errors
I have an implementation ready with 31 new tests (all passing) and would be happy
to submit a PR
Increasing access
Better parameter validation makes p5.js more beginner-friendly. When a new user calls ambientLight(), directionalLight(), pointLight(), spotLight(), lightFalloff(), specularColor(), or noLights() with incorrect arguments, they currently get cryptic runtime errors or silent failures. Adding friendly error messages through p5._friendlyError()
helps users understand what went wrong and how to fix it - directly supporting p5.js's mission of making creative coding accessible to everyone, including those new to programming.
Most appropriate sub-area of p5.js?
Feature enhancement details
Seven WebGL light functions in
src/webgl/light.jshave commented-out parameter validation (// p5._validateParameters(...)) and TODO comments requesting parameter checks (//@TODO: check parameters number).Affected functions:
ambientLight(line 176) - commented-out validationspecularColor(line 407) - commented-out validationdirectionalLight(line 587) - commented-out validation + @todopointLight(line 813) - commented-out validation + @todolightFalloff(line 1069) - commented-out validationspotLight(line 1289) - commented-out validationnoLights(line 1352) - commented-out validationAdditionally, the renderer-level implementations in
Renderer3D.prototype.lightFalloffandRenderer3D.prototype.spotLightuseconsole.warn()instead ofp5._friendlyError(), which is inconsistent with the Friendly Error System.Proposed changes:
p5._validateParameters()with argument count/type checks usingp5._friendlyError()console.warn()calls top5._friendlyError()this) on validation errorsI have an implementation ready with 31 new tests (all passing) and would be happy
to submit a PR