When creating the custom MyBlocks using Java code, trying to return a List Double> for instance will not allow the blocks to snap together. Yet to test this but it will probably throw a runtime error if I managed to plug the java block into a variable, and then that variable into a List block.
It seems to me the only way to provide Blocks and Java List compatibility is to use the JavaUtil and the type insecure List interface. Should I create a bug/feature-request for this on the FTCRobotController Github?
I will admit that I am not the resident Blocks expert here (@lizlooney is), but what is “bad” for one language is a “boon” for another. You are correct that in many languages a typeless anything is generally a bad idea - in general most languages benefit from a strong type-safe environment. However, Blocks was designed to remove the burden of most types on programmers - this is seen as generally a “good thing” for the level of programmer that Blocks is designed for. However, as you have pointed out, this requires languages that interface with Blocks to include a lot of overhead that generic use of the language would strongly recommend against. C’est la vie.
Can Blocks export type-safe Java code? I dunno, to me that might be a LOT of work with little benefit (in my mind if you want Java code, learn to create Java code, otherwise the java export is just for show). However, I will let @lizlooney provide any additional details or thoughts.
I have just discovered that Blocks doesn’t provide any compatibility with Lists of any type (from java code), which is disappointing considering my teams needs. Or at least the blocks aren’t plugging in together. Seems like the type insecure list change did not have any effect.
I’m the java programmer on the team, the rest of the coding team uses Blocks. One of our mentors suggested that we use blocks as a “Control flow diagram,” where we can visualize everything and the advanced stuff is in the background (Java). So mainly that is why we are using this feature.
There is also the advantage of being able to change code/configuration on the fly, instead of waiting for the java code to compile (it takes around 2.5 minutes to compile). For this we need all the important variables configured in the top level Blocks environment, which unfortunately includes some lists.
I understand now that typesafe code compatibility would be too much work for little benefit, but List compatibility seems to have a bit more benefit. I don’t know how many hybrid approach teams there are out there, but it seems like it would be beneficial.
For now (since this is obviously not a quick API change) we may have to hide more of the configuration lists, and/or have 20 variable blocks. The functions that return lists will probably have to be run internally.
The “length of” and “is empty” blocks from the Lists category will work correctly on Java arrays and Collections, but I’m not sure about whether you can plug a MyBlocks that returns a List (or Java array) into those blocks. You might have to use a variable.
I hope this helps. In general the purpose of showing the blocks-to-java generated code is to help Blocks users become familiar with what java code looks like. But, as you’ve noticed, sometimes the code that is generated is not the way a human Java programmer would do it.
Interesting. So Blocks can pass around variables and objects of unknown type?
In the case of my code it is a bunch of numbers (a configurable grid) passed into the java methods. I’m guessing that keeping that part of the front end will involve a lot of .add() operations instead of a single list. The alternate is hiding this altogether from blocks and just putting it in java.
I will try to work on creating the feature request when I have time, but I think this will be a valuable feature.