Translate types

[bmcage]

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:

typeName: function() {return Blockly.Msg.ARD_TYPE_CHAR;},

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?

[carlosperate]

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 typeName, as you have implemente here, is required.

I've briefly played with the idea of adding an accessor instead of using typeName as a function:
7dec25e (in a branch)
The only problem is that I am not quire sure if the typeNameMsgId argument for the constructor is very clear, any thoughts?

[bmcage]

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) ...
So for me both work, depends on what you find most clean.

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)

[carlosperate]

I think I will merge the accessor for typeName, with the difference that instead of typeNameMsgId I'll rename the argument to typeMsgName. As long as it is documented properly it should be fine.

As a side, would it not be cleaner to have also in core a subdir arduinotypes?

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.

[carlosperate]

Added on a819427.
Also notice that I corrected the "short positive number" string to "short postive", as the type is char, a signed byte.

[bmcage]

Ok, I follow your reasoning.
On my suggested solution to using variables for digitalwrite in #70 you see I use types to drive this mechanism. Those types are even further from what other languages might need. However, there is the addType function, though it is nowhere used and it had a bug. So a possible way forward is perhaps a part in core like coreArduino.js, with specific Arduino use of the type system, using this addType function? If somebody wants to use types for a language other than Arduino, they will have an easier time splitting out the Arduino stuff.

[carlosperate]

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.