-
Notifications
You must be signed in to change notification settings - Fork 280
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
Translate types #69
Translate types #69
Conversation
Thanks for the prompt submission! I've been giving the typeName implementation some though, and it looks like there might not be a very clean way of doing it. Assignment of the Blockly.Msg is not really a good idea even if the instantiated object was already present on init. This is because a "dynamic" language change without page refresh would bypass this translation completely. So retrieval of the current string on each access of I've briefly played with the idea of adding an accessor instead of using |
Number of Types will be a limited thing for any language, so although typeNameMsgId is not very clear, having to pass a function is also awkward. The only drawback is that only in types.js this construct is used, but in the future that might change (same for the function) ... As a side, would it not be cleaner to have also in core a subdir arduinotypes? It seems to me we are adding types specific to arduino in the core lib, while a different language might reuse the construct of types, but would need other (or different compatibility). What I mean is some way that the arduino specific typing (short number, long number) is not present when doing dart/python/...(this is not something I have the js skills for to pull off) |
I think I will merge the accessor for typeName, with the difference that instead of
I did consider this when I was first looking into adding "non-standard" types with compatibilities, but the problem is that the blocks have to be independent to the generators. If we look at the default "blockly code" example, the same blockly workspace is used to generate all the different languages, and there is no way to select which "language" rules the workspace wold follow for block connections. Because of this, the fact that the codebase will inevitably diverge more and more with time, and the almost non-existent need for Ardublockly to support (and maintain) more languages, I though that doing it this simpler way is an acceptable trade off. |
Added on a819427. |
Ok, I follow your reasoning. |
Oh, I see what you mean. Yeah, that sounds like a great idea, since most of the "arduino specific" types would only be used by the arduino blocks. This keeps the generic blockly working, but we would still have the same problem if somebody wanted to use the Arduino blocks to generate other languages. As far as I can remember, the only blocks that need a type not defined in the original Blockly would be the number blocks, which right now differentiate between integers and floats. There might be others, so we'll have to have a careful look. Sorry I missed #70, I'll have a look tonight. |
Translate types
This PR allows cast block to be translated, see issue #67
Had quite some issues making this work compressed. My solution at the moment is using a function. So you will see eg:
This because Blockly.Msg is only available on init, so when the types are created, this is still undefined. Using a function means translation is deferred till later.
Perhaps there is a better solution? Eg adding typeName after translation is loaded?