AnswerHub Upload Issue
Our AnswerHub community currently has a bug that prevents you from attaching your model or other files to your questions. AnswerHub is aware of this issue and they are working on a fix. Until we receive their patch, you can upload your models and other files to FlexSim's file share site. Include the file name in your question so that we know which upload to reference.

Idea

Mischa Spelt avatar image
6 Likes"
Mischa Spelt suggested Mischa Spelt commented

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
}
flexscriptcodecommandstree node
5 |100000

Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

1 Comment

·
anthony.johnson avatar image
5 Likes"
anthony.johnson commented

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:

  1. 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.
  2. 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...
  3. 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.
  4. 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
5 |100000

Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

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 Like 1 ·

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 Likes 0 ·
Mischa Spelt avatar image Mischa Spelt anthony.johnson ♦♦ ·

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 Like -1 ·

Write a Comment

Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

Your Opinion Counts

Share your great idea, or help out by voting for other people's ideas.