What to do about array methods? (forEach, map, filter)
Closed this issue · 15 comments
I am slightly confused about the existing array methods in basil.
There are the methods Array.map() and Array.filter().
Then there is the method forEach, which seems to do the same as JavaScript's Array.forEach(), but it has a different syntax forEach(array, callback), so is not an Array method, but an independent function.
Then there are some methods that exist in JavaScript, but are missing in basil (reduce, every, some, find – any more that I am missing?).
What should we do about this? I see these options:
- Make them more consistent and make forEach a true array method.
- Make them more consistent and add missing ES6 array methods (reduce, every etc.).
- Take them all out for basil.js 2.0 and let users use a more dedicated lib for such functionality (underscore.js?).
@basiljs Which of these options do you guys prefer?
- Yes
- We Could. See https://github.com/ExtendScript/extendscript-es6-shim and https://github.com/ExtendScript/extendscript-es5-shim
- As the most of the audience for Basil are beginners and intermediates in classrooms I think It would be a nice helper to enable them to use modern JS functions you find all over the net in Basil without being forced to find the polyfills they need. On the other hand it creates a lot more code to watch over. :-)
Ok, so in the first step, we could just make forEach() consistent. Then in a second step, we could add the missing methods. Which ones are that?
reduce, every, some, find? Any more?
- +1 consistency
- could we not simply include the functionality via an external lib e.g. an old
underscoreversion? That way we would not have to deal with it ... - +1 Would be nicer to have it shipped and included out of the box with basil 2.0
Did you take a look at the shim repos? We could include them into the build process by installing them via npm (es5 shim is already on npm https://www.npmjs.com/package/extendscript-es5-shim) and I can publish the es6 as well. These are tested and work out of the box. No including for the enduser. Just something like
main.js
//@include '../node_modules...' and so on
Or if the relativ path does not work we create some pre build process that copies the shim to the src folder.
Is this just for the few array methods? To be honest, I would just implement them via hard coding ("hardcopying") over the polyfills and be done with it. Or am I missing something here?
Going old school? :(
Ok, I don't seem to get it. What is the advantage of the implementations described above? I feel like before I even understand how to do the implementations like that, I am long finished quickly hard copying those five methods.
The polyfills don't really change over time anyways, so I don't understand, what's the advantage of including them from some external place.
Well if there is an issue or a new polyfil we get an update just by pulling that repo/npm update
Ok, I now had a look at the es5-shim repo.
All in all there are polyfills for 25 es5 methods. I find this way to much to include, especially since some methods are some fairly specific and specialized functions, which kind of go against the spirit of basil. Also, if you include these, then why would the es6 methods not also be included and so on, it becomes hard to draw a line. So I would be against including them in the first place.
The question is what else to do?
If we have a look at the motherships Processing and p5.js we have these Array functions:
These are true functions in the sense that for example sort has the syntax
sort(list, [count]);as opposed to the JS array methods
arr.sort([compareFunction])To be honest, I rather think we should follow that path, remove the existing array methods, and (sooner or later) implement these processing and p5 functions, instead of adding ES5 polyfills. If a user needs the ES5 methods, they could use a dedicated library for that, I don't think it should be basil's job to offer these methods.
What do you guys think?
No problem for me to follow the p5 path ... it just seems to be quite some work for very little gain. Hence if I had to implement it, I would just be very programatic and go for the ES5 methods (as they come "for free").
I would just be very programatic and go for the ES5 methods (as they come "for free").
Me too.
I just find there are too many too specific methods, that don't really fit to basil at all and would bloat it up to much. Here are some of the methods:
I mean, Array.reduceRight(), Object.isSealed(), Object.getOwnPropertyDescriptor() etc. ...? I have never even heard of these methods and I don't think we need them in basil at all (also this is just the ES5 methods, ES6 would probably add some more).
Therefore my suggestion is: As we have the unique chance to break backwards compatibility with basil.js 2.0, I would take out all Array methods for the 2.0 release. Later we can bit by bit implement the p5/processing Array functions (there is no really hurry for that, but taking out the Array methods can only happen with the 2.0 release).
What are your thoughts?
Edit: Also, if we now decide to go with the ES5 methods and later want to add the p5/processing functions, we cannot just take out the ES5 methods again, as it would break backwards compatibility, which would pose a real problem as well.
Therefore my suggestion is: As we have the unique chance to break backwards compatibility with basil.js 2.0, I would take out all Array methods for the 2.0 release.
OK with me. Pros can add it easily on their own.
We just will have to carefully check every example whether it has a array method used.
We just will have to carefully check every example whether it has a array method used.
True, good that you remind us of that.
Actually the ES5 stuff could also become one of the "plugins/libraries" for basil we were planning on offering (once we have at least three 😉 ). That way the core stays clean, but people could still use the methods, if they prefer to.