-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Plans for string prototype methods? #65
Comments
I think it is a similar answer to #64, however, the index (str[0]) format seems to be not implementable without parser/engine support. |
Yeah, it's a similar story. But unlike arrays, Microvium does not have a mechanism to self-reflect on the content of its own strings. The reason for this is that strings in Microvium are defined as being UTF8-encoded, since it's potentially more compact and more aligned with what people commonly use in C, whereas the ECMAScript standard defines it as UTF16. So, a spec-conformant implementation of Roughly speaking, your options are:
|
What I'm trying to implement is sending messages with Bluetooth to the device and to the Microvium engine. These are string messages with different content. The device should be able to process them with a JavaScript code. Also there are buttons on the device, and I would like to process button presses as well. Different sources are sending different messages on a generic string interface. The device also have an RGB led and a vibration motor. When I'm sending "%rgb", I would like to set the RGB led to red, then after 0.5s then to green for 0.5s and finally to blue for 0.5s. When I'm sending "~...---..." the vibration motor should play SOS vibrations. I would like to enter numbers with the numeric buttons, like 1234. My idea is appending every digit, and checking the string length. When it is 4 digits, I would like to do a calculation with it, and then send a Bluetooth message to an other device. This would be a generic tool that can process, transform events and data, etc. I would like to allow users to write code and create their solutions. I also would like to write some code in JavaScript to accelerate development. So in general, I would like to do basic text processing. I see there are workarounds, but would be great to keep it simple and easy to understand. It's hard to explain Uint8Array. I think iterating over UTF-8 strings to figure out the 6th character is not a problem, it will be quick for most of the cases. Same for length. As the strings are mostly short, I would be happy to go with that as an MVP solution. I'm not working with non ASCII strings, but maybe later it will be necessary, I know this problem. |
Ok, I'll take a look at it. I propose the following solution:
I believe that this is the minimum that would be required for a user to write all the other string methods, e.g. in the form of a library. |
Oh, this sounds awesome. Thanks a lot. I agree that having these will allow me to implement all the features I would like to. |
Probably I've closed this issue by accident. Your proposed solution is great. |
When do you think you can add these features? (No pressure) |
Hi. Sorry, my 2-year-old started going to childcare earlier in the year and suddenly started catching all these viruses from the other kids and has been sick almost constantly since then and it took all my energy and time. I'm starting to get back on track now, but I want to close off a few half-completed branches/features before I start on this one. Let me see what I can do. Apologies for the long delay. I'll see if I have time later this week, otherwise we're looking sometime in August probably. |
No worries. Mines are 11 and 13, and it is still happening. :D 🤞 Thanks, and looking forward for the updates. |
WIP - the branch Unicode support is a rabbit hole and I'll need to resume it another time. My revised proposal is this:
The reason for the |
Sorry, this isn't likely to happen any time soon. I'm swamped with other things. If anyone else wants to pick up this work and contribute or help, the branch is |
How important are the string prototype methods? I'm encountering multiple problems in the implementation. The first is that I don't want to force a whole object to be allocated in memory for people who don't use that feature. I think I can get around this by saying that the string prototype object is allocated lazily at compile time. So if you access The second problem is more significant which is that in the spec, method calls on strings will pass a ''.__proto__.myMethod = function () { console.log(typeof this) }
'abc'.myMethod(); // Logs "object" not "string" Microvium doesn't have these wrapper types like the I could leave it non-compliant and just pass So the question is, how important is it? And, can you (or anyone reading this thread) think of any other clever ways of supporting it in a way that is compliant and doesn't add much cost to those who don't use the feature? |
Hi, from a JavaScript developer's point of view, I think they are a very important feature of the language. Even basic string manipulation is hard without them. Please note, that in JavaScript, strings are most of the time NOT objects, ONLY behaving like objects. Probably this is the solution you are looking for. https://developer.mozilla.org/en-US/docs/Glossary/Primitive
Of course, you have to consider what are the use cases of Microvium you would like to support. My idea is that if you have a device that has a display, you most probably work with strings, and likely to have to manipulate them. |
I think passing the primitive value as |
As far as I see, even basics like [num] to access a character, or length property are not supported (there's a reference in the string test, but only as a comment). What is the plan about adding these, and basics like substr, indexOf, split, charCodeAt and fromCharCode? If there's no plan, how do you think it is the best to implement these?
The text was updated successfully, but these errors were encountered: