The too many arguments anti-pattern

[ff6347]

While working on the reference I noted that we are having an JS anti pattern in Basil (IMHO). We have functions like rect(x, y, w, h, [tl], [tr], [br], [bl]). I know this is due to the relation to Processing but I find this pretty un-js-like. In my opinion this should actually be.

rect(options)

To keep it comparable to Processing and P5.js I would suggest something like this.

rect(x, y, w, h, options)

The rule of thumb could be all optional arguments are packed in an object. It would be even cooler if we could have both:

rect(x, y, w, h, options)
// and
rect(options)

This is nothing I need to happen for v2.0 but I wanted to start a discussion about it.

[ff6347]

There is a eslint rule for that https://eslint.org/docs/rules/max-params

[trych]

I disagree and would stay in sync with Processing and p5.

In most of the cases users will want to use rect(x, y, w, h) only and then it does not matter, if there are 4 more optional arguments that could be used. In the cases where they need differently rounded corners, then they will be fine listing 8 numbers there.

I don't see the big benefit of moving these into an options object and therefore sacrificing staying in sync with Processing and p5.

[ff6347]

I'm not sure which is the right way. Having so many positional arguments feels wrong to me. But this comes from years of writing code.
Would be interesting to make a survey with users/students what they think about it. Is it easier to have all those positional arguments or would it be easier to pass in an object.

In terms of "staying in sync wit P5…" you are absolutely right. In terms of usability I'm unsure…