You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This would be quite a significant change and probably require a lot of work, but I think it would be quite useful.
Currently, a block in Waterbear has an exact fixed number of inputs, which are either sockets (for holding expression blocks) or contexts (for holding a sequence of step blocks).
I think it would be useful to have blocks which can support a variable number of sockets — in the UI, you'd have a + button to the right of the last socket which, when clicked, adds a new socket to the block. The most obvious places to use these would be for an array literal block or an object (dictionary) literal block, allowing you to define an entire array or object with a single expression block. It would require some added complexity to the script template syntax though, especially if supporting something that would be suitable for an object literal.
I also think it would be useful to have blocks which can support a variable number of contexts. In this case, the UI would have a + button at the bottom, or possibly a dropdown menu to select between two types of extra context (for example, "else if" or "if" in an "if" block; maybe even "case" or "default" in a "switch" block). There's the potential here for the added context to come with some slots preceding it, but for the simplest cases (adding "else" to an "if", or adding "catch" statements to a "try") this would be unnecessary. Again, this would require some added complexity in the script template syntax. One idea would be to internally represent the added context as a sort of "child" block which can't be moved separately from its parent and is permanently attached directly below it. As far as conversion to code is concerned, it could be seen as two consecutive blocks (eg, an "if" block followed by an "else" block), but at the UI level the two blocks would be treated as a single monolithic block.
The text was updated successfully, but these errors were encountered:
This would be quite a significant change and probably require a lot of work, but I think it would be quite useful.
Currently, a block in Waterbear has an exact fixed number of inputs, which are either sockets (for holding expression blocks) or contexts (for holding a sequence of step blocks).
I think it would be useful to have blocks which can support a variable number of sockets — in the UI, you'd have a + button to the right of the last socket which, when clicked, adds a new socket to the block. The most obvious places to use these would be for an array literal block or an object (dictionary) literal block, allowing you to define an entire array or object with a single expression block. It would require some added complexity to the script template syntax though, especially if supporting something that would be suitable for an object literal.
I also think it would be useful to have blocks which can support a variable number of contexts. In this case, the UI would have a + button at the bottom, or possibly a dropdown menu to select between two types of extra context (for example, "else if" or "if" in an "if" block; maybe even "case" or "default" in a "switch" block). There's the potential here for the added context to come with some slots preceding it, but for the simplest cases (adding "else" to an "if", or adding "catch" statements to a "try") this would be unnecessary. Again, this would require some added complexity in the script template syntax. One idea would be to internally represent the added context as a sort of "child" block which can't be moved separately from its parent and is permanently attached directly below it. As far as conversion to code is concerned, it could be seen as two consecutive blocks (eg, an "if" block followed by an "else" block), but at the UI level the two blocks would be treated as a single monolithic block.
The text was updated successfully, but these errors were encountered: