DRAKON polymorphism and operator overloading

[ACJA]

While officially DRAKON is not supporting function/method polymorfism (and for that reason operator overloading is not supported also as a diagram), there is a work-around way to implement standard polymorfism on DRAKON diagrams. The back-door is left open by DRAKON enforcing mechanism for unique names. While in a code sequence spaces are discarded, DRAKON will interpret one or two spaces as one or two independent characters. Hence, renaming a function with a blank or more in front of the name will force DRAKON to consider that function name as distinct; two or more functions with the "same" name are allowed now and the polymorphism can be implemented. For operator overloading, one must place one or more blank spaces in between the "operator" keyword and the following operand. Also, avoid using a blank or TAB in front of main return statement, DRAKON will place for some reason the return statement twice. This is an especially nasty bug, adding a double return statement. While in most of cases it is enough to avoid TAB or spaces, DRAKON will enforce adding a "return void" if no return is specified. DRAKON will forbid using any conversion operator defined as a method or function diagram, since a conversion operator must be used without any "return" statement (DRAKON will force on your code the "return void" bonus line on any conversion operator function definition). In DRAKON, all conversion operators must be defined in the properties list as simple code lines. The attached archive contains some DRAKON examples with true polymorphism and with operator overloading. The "run.prj" script will process the existing DRAKON diagrams all the way down to the executable. Associate and/or open this script in a terminal to see the program output. examples.zip

[stepan-mitkin]

C/C++ code generator has been cleaned up. It does not produce redundant return statements anymore.

[ACJA]

Many thanks for your work.