ATTENTION

This FlexSim Community Forum is read-only. Please post any new questions, ideas, or discussions to our new community (we call it Answers) at https://answers.flexsim.com/. Our new Question & Answer site brings a modern, mobile-friendly interface and more focus on getting answers quickly. There are a few differences between how our new Q&A community works vs. a classic, threaded-conversation-style forum like the one below, so be sure to read our Answers Best Practices.


flexsim.com

Go Back   FlexSim Community Forum > FlexSim Software > Gripes and Goodies
FAQ Downloads Calendar Search Mark Forums Read

Gripes and Goodies Software problems and suggestions

Reply
 
Thread Tools Display Modes
  #1  
Old 03-25-2013
brett forbes brett forbes is offline
Flexsim User
 
Join Date: Oct 2011
Posts: 34
Downloads: 0
Uploads: 0
Thanks: 27
Thanked 3 Times in 2 Posts
Rep Power: 100
brett forbes is on a distinguished road
Thumbs up Proposal for Flexscript Extensions - OOP Collections and pointers in tabsles

Hi,

I have been using Flexsim for only a short while, and yet am very impressed with the architecture and approach of Flexscript. I offer below some comments which I believe would significantly improve the language, and ease development.

Background
While the underlying model in Flexsim is object oriented, the programming in Flexscript is more procedural. This is not a problem normally as the code is generally concise, although there are some situations where it is not (e.g. table operations).

In general, all of the needed data types are available and nicely integrated, yet Flexscript lacks a key capability common to most OOP languages (e.g. Scheme, Lisp, Delphi etc), in particular the use of collections.

Collections are a critical part of OOP, as they enable the data to be aggregated into objects, which is critical when dealing with complex situations. In particular collections contain different types of data, can be indexed so they point to table rows, and can contain other collections and non-indexed data.

There are many types of collections used in diferent languages, and I offer below some comments on how the most simple collection type, commong to Lsip, Scheme and Delphi, could be used to speed programming and increase performance of the Flexsim models.

The lack of a collection makes dealing with tables (e.g. global tables, database tables) and the many types of data inherent in complex models somewhat clumsy, resulting in somewhat obtuse code. Further the lack of collections makes the handling of large numbers of pointers difficult resulting in the underlying architecture requiring many calls which parse the tree based on text strings, with the attendant performance penalties.

Proposal
I propose below that Flexscript is extended slightly in two dimensions.

Firstly, some additional table commands and capabilities are added so that filling out tables is not as slow or cumbersome (i.e. requiring many, many lines).

Secondly, that Flexscript introduces the simplest collection class, basically a record or a struct (i.e. name depends on the language where you may have used this approach before).

I believe that with these two simple additions, I can demonstrate that you could significantly speed model execution, and make the Flexscrip code even more readable and concise.

1. Enhancements to Existing Table Capabilities
I note that the table structure is the best data structure available in Flexscript, as it is completely dynamic, unlike arrays, enabling you to expand it as necessary. I really like the table and offer some comments on improvements below, in particular the need to add explicit pointer support.

One of the biggest problems in using tables in more complex instances (e.g. setting up section tables for conveyors or pipes) is that each cell in the table must be set individually. Thus if you want to setup a new row in a table with 8 columns, you need at least nine lines of code to achieve it.

This could be improved with some simple additions:
1. A new flag on the AddTable Row command which enables you to copy the values of the last row into the newly added one. This would be very useful with pipes as many of the columns are always the same (e.g. thickness, show joint etc).
2. A CopyTableRow command, enabling you to copy data from one row to another. This has similar functionality to the above command, but is useful in different circumstances.
3. A SetTableRow command, which enables you to set the values for all columns of a single row in a single command
4. Finally, explicit support should be provided for treenodes inside global tables (i.e. select three different data types for any column), and this would enable you to tighten up paramater checking inside the table commands

2. Data Collections
This assumes the four changes listed above are provided.

I propose that the simplest form of a data collection is provided, that of a record or a struct, which can contain multiple basic data types (i.e. double, integer, treenode). I propose that this basic concept is extended as follows:

1. The record can contain multiple data types (ie. integer, double, treenode)
2. The data variables are accessed through the dot nomenclature (i.e. myrecord.datavalue)
3. The records can contain other records ad infinitum
4. The record is setup so that it can use an index, inside square brackets like an array, which enables it to index a row in a table (i.e. myrecord[i].datavalue)
5. The record can contain non-indexed variables (i.e. do not connect to the table)


Proposal Outcomes
If my proposal is adopted, I believe that it would massively change both the efficiency of coding and the efficiency of running the models. Consider the following:
1. By adding explicit support for treenode pointers in the global tables you enable large models to simply and easily keep track of all objects by using tables.
2. By setting up the collection as proposed, all user data can be stored and accessed in object-oriented form
3. By setting up the collection as proposed, the record then becomes the main front end for any table (i.e. global table, database, excel etc), just like in traditional OOP languages (i.e. older than C++)
4. Using the dot nomenclature to access variables inside the collection does not conflict with any current Flexscript standard and is an easy add-on. It is also easy to parse these objects in the script writer and enable people to select the right item from a drop down list once the dot has been pressed.
5. Using the index to the record enables the records to be a simple front end to any table
6. Having variables within the record that do not connect to the table enables the programmer to deal with the situation where some data for an object is a property (i.e. does not change), whereas other data is variable (i.e. needs to be read periodically).
7. A record constructed at the begining of the program could contain the entire tree as a pointer set, enabling one to point at any object without having to do a text string parse (i.e. much faster)

Summary
Essentially, I propose some changes to the table capabilities to enable it to be highly versatile. While it is great at present it lacks explicit support for pointers and is a bit clumsy when adding lost of data. Further I propose that a data collection be designed that would enable OOP data handling to be utilised. There are huge coding and performance benefits to such a scheme, and few downsides (i.e. apart from the programming effort).

Frankly, there are too many benefits of the scheme listed above to enumerate, but I would be happy to enagage in further discussion on this topic.

Thanks

Brett
Reply With Quote
The Following User Says Thank You to brett forbes For This Useful Post:
Anthony Johnson (03-26-2013)
  #2  
Old 03-26-2013
Anthony Johnson's Avatar
Anthony Johnson Anthony Johnson is offline
Manager of Product Development
 
Join Date: Jul 2007
Posts: 440
Downloads: 86
Uploads: 4
Thanks: 171
Thanked 899 Times in 288 Posts
Rep Power: 728
Anthony Johnson has a reputation beyond reputeAnthony Johnson has a reputation beyond reputeAnthony Johnson has a reputation beyond reputeAnthony Johnson has a reputation beyond reputeAnthony Johnson has a reputation beyond reputeAnthony Johnson has a reputation beyond reputeAnthony Johnson has a reputation beyond reputeAnthony Johnson has a reputation beyond reputeAnthony Johnson has a reputation beyond reputeAnthony Johnson has a reputation beyond reputeAnthony Johnson has a reputation beyond repute
Default

Brett,
First, a few comments on the table stuff.
1. You can pretty easily copy one row of a table into another row with:
Code:
createcopy(rank(theTable, fromRowNr), rank(theTable, toRowNr), 0, 0, 0, 1)
Specifically, make sure the replace parameter is 1, in which case it will replace the row with the copied row.
2. You can have table cells contain pointers to nodes. You can use the pointer coupling data type:
Code:
settablesize("MyTable", 3, 3, DATATYPE_COUPLING)
To set a table cell value:
Code:
nodepoint(gettablecell("MyTable", 3, 3), myNode);
To get a table cell value:
Code:
treenode myNode = tonode(get(gettablecell("MyTable", 3, 3)));
Although by "explicit" support, you may mean that we should have table commands like gettableptr(), settableptr(), instead of the weird commands above. I see your point there.

And finally, regarding the flexscript suggestions, I appreciate your feedback. I have been mulling over in my mind over the past few years how we would go about adding dot syntax, i.e. collections, into flexscript. One of the big advantages I see would be to be able to access methods of classes defined in c++. For example, instead of all these globally defined rack... commands that just forward stuff to the c++ Rack's methods, wouldn't it be nice to just have a rack type in flexscript so you could just access the methods directly through flexscript. The main challenge I see is that whatever we do we would need to keep compatibility with c++. We've always tried to stay close to c++, specifically since the library objects are implemented in c++, and any future library development will be done in c++, and perhaps because we don't claim to have the confidence/hubris to blaze our own programming language trails. So I think going forward we're going to find solutions that continue compatibility with c++. It doesn't mean it's impossible. Obviously, c++ has dot syntax, so what's the problem, you might ask. Well, the devil's in the details. Again, it's not impossible, it's just another wrinkle that we have to keep in mind that makes things more complex. Especially since during run-time, execution of the model is quite frequently switching between c++ code and flexscript code, we want a solution that will be cross-compatible. We're already starting to add some features in c++, through our module SDK, that use array-type syntax for dereferencing lists of nodes. Wouldn't it be nice to have some of that same functionality in flexscript.
Reply With Quote
The Following 3 Users Say Thank You to Anthony Johnson For This Useful Post:
brett forbes (03-26-2013), Steven Hamoen (03-27-2013), Vadim Fooks (04-28-2013)
  #3  
Old 03-26-2013
brett forbes brett forbes is offline
Flexsim User
 
Join Date: Oct 2011
Posts: 34
Downloads: 0
Uploads: 0
Thanks: 27
Thanked 3 Times in 2 Posts
Rep Power: 100
brett forbes is on a distinguished road
Thumbs up Suggestion - start with the minimum necessary

Hi Anthony,

Thanks for your feedback, and you make some excellent points as usual.

I guess where I was going with the record/struct idea is that it is the preliminary collection in object orientation.

What I mean by this is it just handles data in an OOP format and doesn't have the embedded methods or procedures of a full object definition. This means you don't have to worry about a whole load of stuff necessary for a full object definition, like public and private, and so on.

So I see it as a "baby" object. However, I have found in practice, perhaps because of my poor programming skills, that this most simple means of collecting and refering to data is actually extremely powerful, particularly when accessing tables, and doesn't have the overhead of having to worry about methods and access properties.

I have checked on my c++ reference and found that the concept I am looking for is actually a struct (http://www.cplusplus.com/doc/tutorial/structures/).

I think implementing a struct would be powerful and highly useful, whereas implementing the full class definition (http://www.cplusplus.com/doc/tutorial/classes/), would create a lot of overhead which obviates the reason for Flexscript in the first place.

As a scientist I am often dealing with real world situations where my parameters are of three types:
1. Variable - change all the time and need to be read from tables or calculated at each time step
2. Properties - change between different instantiations of the same struct but persist for the life of that instantiation
3. Constants - which are the same for every instantiation

Currently, representing these situations in Flexscript requires a lot of global variables, and unecessary calculations. So I see huge advantages in heirarchical structs, such as
Code:
struct myphysicsobject{
struct myVariableData[i]
struct myPropertyData
struct myConstantData
} myinstantiation
Personally, I wouldn't want the overhead of representing this as an object as I then have to design a whole load of user commands simply to hide some of the details because of some philiosphical argument about encapsulation.

Further I am concerned that in very large models (i.e. your 64-bit system) all of the text string parsing used to find objects creates an overhead, which is why people often refer to items through indexes. Yet indexes produce obtuse code, wheras the dot nomenclature produces far more readable code.

So I see huge value in a global pointer struct that exactly represents every object in the tree at all times. In my view the memory overhead of this is quite small (e.g. a couple of bytes per treenode), yet the performance improvements in code would be significant as string parsing of treenodes becomes the exception rather than the rule.

In my own code i always setup treenode pointers at the begining of every function, yet it seems to be a waste to do this dynamically, every time I run that function, and I don't want to do it all at the begining of the model and have hundreds of global variables. And the array of treenodes is a fixed size and can't expand and contract as needed.

So I see the struct as being the perfect halfway house. It is completely compatible with C++ and can access every object, yet it is still simple enough so that the programming overhead is small and Flexscript retains all of its benefits. It is also completely compatible with your table collection, as long as it is row indexed as described above.

Of course, as you point out, the devil is in the detail, so there is the question of how to connect these structs to the C++ objects or tables in the background. But I will leave this up to you gurus

I completely agree that a nice, flexible way of dereferencing tables, current objects and any future objects using dot nomenclature would be awesome.

So when can I start using it? hahahah

Anyway, I appreciate your comments on tables, as I wasn't aware of the DATATYPE_COUPLING, and i appreciate the opportunity to put forward some simplistic ideas on enhancements to your most excellent product.

Thanks

Brett
Reply With Quote
Reply

Tags
flexscript extensions

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
convert C++ code into flexscript ameen shabeer Q&A 2 12-08-2012 09:52 AM
about flexscript Kang Han Q&A 2 10-03-2008 09:21 AM
Static Variables in Flexscript? Joe Allen Q&A 7 09-18-2008 12:43 PM
size of arrays in Flexscript Steven Hamoen Q&A 13 06-23-2008 01:04 PM
Clean Flexscript Steven Hamoen Q&A 1 04-04-2008 07:00 AM


All times are GMT -6. The time now is 06:41 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Copyright 1993-2018 FlexSim Software Products, Inc.