Idea

Mischa Spelt suggested Nov 22, '16 Mischa Spelt commented Nov 25, '16

Extensions to language

Just a quick request for two extensions to the language, one minor, one a bit more involved.

1. Love the new dot syntax! But subnodes.length feels way too long for something we used to have content for. I'm not mentally ready to say goodbye to content yet. At least could we have it as a getter on treenode, please? (Setter is optional, after all writing treenode.content = 4 would be cool but not critical).

2. Was thinking about what I use content for the most, and it is in loops. Why not get rid of

for(int i = 1; i <= node.subnodes.length; i++) {
  treenode subnode = node.subnodes[i];
  // .. Use subnode
}

in favor of

for each( treenode subnode in node.subnodes ) {
 // .. Use subnode
}

anthony.johnson commented Nov 22, '16

Mischa,

Thanks for your feedback. There have been quite a few discussions on our side regarding this very decision. Initially we designed it to have a property treenode.numSubnodes, and a method treenode.subnode(name, assert). We decided we did not want to use the word "content", because it's used in no other languages that I've seen, and the word content does not technically mean "number of things inside" but rather "things inside", and thus could be deceptive for a new user (although I admit the same thing can be said for length). The numSubnodes property, while pretty explicit in meaning, just didn't sit right with me, so we threw around different ideas. Other languages we've seen use either length, size, or count. All of those have their own ambiguities. I partly leaned toward count, but since it could be a verb or a noun, and count already has a different meaning in FlexSim, we decided on length.

The reasons we decided to put it on the subnodes property instead of floating it to the treenode are several fold:

Although "length" can have its ambiguities, this usage makes the code much more intelligible to someone who is learning. By the fact that you're working on node.subnodes, it's pretty clear that you are looking in the node's subtree.
You can technically store a variable as subnodes and then traverse that. var subs = node.subnodes; Obviously that's still not as simple as content(), but for what it's worth...
Giving subnodes an array-like interface gives more consistency, and imo allows new users to grasp things quicker. treenode.subnodes, treenode.labels, Object.centerObjects, Object.inObjects, Object.outObjects, and Array all have a very similar interface, where length tells you how many things there are. And we plan on adding more to that going forward (Object.subobjects??, ControlPoint.connections, etc.) So if a user learns treenode.subnodes, it's easier to then grasp the other collections.
The new FlexScript usages were designed primarily for novice and learning coders, and specifically for making expression writing in Process Flow simpler, easier to learn, and more consistent. Given that, traversing a node's subtree takes a lower priority as that isn't really required that often. As such, in this case we opted for consistency with other usages in FlexScript over conciseness in a for loop. I'm sure there are other examples where in new FlexScript the code might be longer than before. That's just the natural result of our goals in this, which were not just to make the code shorter (although in some cases, such as label usage, that is the case).

I do agree with your suggestion to make a for loop that loops through the elements in a collection. Our consistency in design will actually make that easier.

· 3

Mischa Spelt commented · Nov 22, 2016 at 05:59 PM

Thanks for the extensive and complete answer. Would upvote, if it didn't give me an internal server error.

I understand the design decisions, and propose to put the "for each"-like construction on the dev list for some future time then (I guess it will take some time because it is potentially a bit of a can of worms -- will you go for some iterator construction such as C++ has, or go towards something like an IEnumerable interface, but we don't have interfaces...).

In the mean time I guess I will have to leave content behind and learn to deal with the hole in my soul :)

1 ·

anthony.johnson ♦♦ Mischa Spelt commented · Nov 23, 2016 at 05:07 PM

We haven't discussed it much at this point, but we're probably not, at least initially, going to implement C++ style iterators with begin() and end() methods. A simple for (var x in blah) should be a good start, as well as maybe for (var x, int key in blah). I'll put this on our dev list.

0 ·

Mischa Spelt anthony.johnson ♦♦ commented · Nov 25, 2016 at 01:41 PM

Another minor request (which I'll add here because doesn't feel like it's worthy of its own thread) is if it would be possible to add a prefix increment operator. We are used to writing ++i instead of i++ in loops, and keep getting errors in FlexSim :) Thanks for considering it.

-1 ·

Idea

Extensions to language

1 Comment

Write a Comment

Things to know…

Your Opinion Counts

IDEA DETAILS

Related Ideas