It was created as a class to facilitate chaining by constantly returning this. That being said, it's not the only way to accomplish that goal.
I don't personally disagree with your point - but I don't necessarily see it as a "contrary perspective" either. IMHO, it's more of an alternate perspective. Maybe that's splitting hairs. But the point is that I can't really see how a class, in this scenario, is wrong, but I can absolutely accept that maybe it's not preferred.
Consequently, I literally just started exploring making this an NPM package. (Like... last night.) And I'm thinking that it doesn't really need to be a class - but maybe a plain-ol' object.
Hmm, a fluent interface does lend itself to OO and OO lends itself to classes, but could be implemented with a plain object too. Not saying this would necessarily be perfect for your use case, but it could be done.
It was created as a class to facilitate chaining by constantly returning
this
. That being said, it's not the only way to accomplish that goal.I don't personally disagree with your point - but I don't necessarily see it as a "contrary perspective" either. IMHO, it's more of an alternate perspective. Maybe that's splitting hairs. But the point is that I can't really see how a class, in this scenario, is wrong, but I can absolutely accept that maybe it's not preferred.
Consequently, I literally just started exploring making this an NPM package. (Like... last night.) And I'm thinking that it doesn't really need to be a class - but maybe a plain-ol' object.
Hmm, a fluent interface does lend itself to OO and OO lends itself to classes, but could be implemented with a plain object too. Not saying this would necessarily be perfect for your use case, but it could be done.
I'm actually implementing it now with a module design pattern. So basically, it's a function... that looks a heckuva lot like a class.
github.com/bytebodger/allow/blob/m...