While
290 GENERATOR DEFINITION
maintaining some sort of collection of already generated objects may help in some
cases, it does not solve the dif?¬?culty of ?¬?nding where two complicated branches of an
IF statement merge back into the main ?¬‚ow. If we want our modeling language to
remain more like a ?¬‚ow chart than an abstract syntax tree, we need our generator to
move beyond sequential lines of code.
The simplest approach is to map each object into its own function. The function
will take care of the actual actions of that object, plus the speci?¬?cation of which
function to call next, possibly depending on a condition. In a Visual Programming
Language (VPL), this approach would generate large amounts of functions, each with
only two or three simple lines of code. In a Domain-Speci?¬?c Modeling language, one
object represents more than just one atomic code operation, so the functions will each
accomplish far more. Of course, we will often be able to spot patterns within the
function bodies, and abstract those out into the domain framework, leaving just a
simple parameterized component invocation behind. While the remaining function
bodies may be only two or three lines long, they clearly accomplish far more than the
atomic operations found in a generic VPL.
In simpler function-based output, each function explicitly calls another function at
the end.
Pages:
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539