Is it planed to have Spread syntax (...) ? No, use arguments instead #1624
Replies: 6 comments
-
Posted at 2021-11-03 by @gfwilliams It has been asked before, but it's not high up my priority list as I feel like it doesn't actually add much, and might be a pain to implement. JS has a built-in
should work on Espruino just fine - no need for spread at all :) |
Beta Was this translation helpful? Give feedback.
-
Posted at 2021-11-03 by @MaBecker Great, so let's use arguments. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2022-09-06 by ch The discussion of ES6 language features is pertinent when using Espruino in a pedagogical context. If one is teaching students contemporary ES6 Javascript, the less one has to say "oh, sorry you can't do that on the Espruino", or "here's a totally different way to do that", the better. For coding pros is not problem to adapt to Espruino's limitations, or to make complicated build chains. But for beginners, this slight variation in syntax switching is not to be underestimated. Wanting to reduce this switch is a major reason we decided to start using Espruinos in our education to begin with. I know it's not a priority because it doesn't unlock new capabilities, but if there is a desire to target the education market as well as hobbyists, language parity should be a goal. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2022-09-06 by @gfwilliams I'd like to add more features and potentially this spread operator could at some point go in, however there are (IMO) more important language features to implement first. There's a wishlist at espruino/Espruino#1302 where you can vote Unfortunately with the current state of JS I don't see that feature parity will ever be possible - it's a moving target and pretty much all the main JS engines out there have teams of people working on them. With Espruino it's really just me and the occasional contributor, and I don't have the resources to keep implementing features at the rate they are announced. Not only that, but we are limited by how much code will fit on a microcontroller. We can't just keep adding features because at some point things will stop fitting - we are already having to strip less-used features from the Original Espruino board virtually every release. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2022-09-08 by ch Thanks Gordon, I appreciate it's a resource-constrained platform, and already you have achieved so much on your own. There is a lot of flux particularly when it comes to web APIs, but ES6 has been around since 2015 or so and is a well-defined target? Is it helpful to make a distinction of ES6 language syntax (such as spread syntax, default parameters etc) versus the ES6 'standard library' of types and functions, eg 'String.padStart', Maps and so on? Could addressing the 'standard library' gap with a polyfill approach be considered? In principle it could be performed transparently by the Espruino IDE, in an optimised way (ala tree-shaking) so that polyfills are only added once and only if needed. This would mean a lighter memory load, even more so if the current standard library is shrunk by shifting less common functions to compile-time includes. It would also be easier for others to contribute to (by writing a 'padStart' function, for example) in contrast to helping with the the low-level Espruino interpreter. Gaps in language syntax, however, require writing code in a different way or introducing a transpiler. Transpiling can potentially produce very verbose code, making it less useful in a microcontroller context. The syntax gap is the bigger obstacle in terms of 'developer UX' in the context we're using Espruinos, not the 'standard library' gap. All that said, I'm way out of my depth with my speculations, so please forgive my ignorance 😅 |
Beta Was this translation helpful? Give feedback.
-
Posted at 2022-09-09 by @gfwilliams Potentially the Web IDE could add polyfills, yes. There may even be some project out there that includes a bunch of polyfills? I know MDN often lists polyfills for 'new' features.
That's true, but my point was more a general one since initially Espruino didn't support ES5 and I worked hard to get most of that implemented. I could spend the next year making sure all of ES6 got implemented and there'd just be another question identical to yours saying: "ES7 has been around since 2016 or so and is a well-defined target?"
Yes, on very constrained targets this would make a lot of sense. But moving compiled C functions to JS does hurt performance significantly.
You might not like it, but this is the obvious method to ensure that all of the newest language features (not just ES6) can get implemented.
I think where it makes sense we can definitely add these features, assuming there is time. Spread as per https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_syntax actually looks doable in a reasonably easy way. The syntax in declarations like However, it's worth noting that some features (like |
Beta Was this translation helpful? Give feedback.
-
Posted at 2021-11-03 by @MaBecker
Just working on a logger function that does not have to take care about the count of parameter. Something like this and like to use the spread syntax:
What do you think?
Beta Was this translation helpful? Give feedback.
All reactions