This however is normally fairly easy to
accomplish by using a different domain framework for each platform, but maintaining
the same interface between the generated code and the framework. In many cases, the
generated code can remain the same and only the framework changes; in others, one
set of generators may still suf?¬?ce, including a few conditional sections that depend on
the platform for which we are generating.
A more dif?¬?cult task presents itself if for some reason we must generate the same
application, but in a different programming language. The information content of the
generated output will be the same, but the distribution over ?¬?les, ordering of the
302 GENERATOR DEFINITION
information in the ?¬?les, and syntax of those ?¬?les will all change. In some cases,
fortunately rare, the best architecture for the application will differ so greatly between
the two languages that the code itself will be largely unrecognizable.
None of these of course presents any problems to the modelers: they simply build
one model and choose which generator to use. The hard work of building two parallel
generators is left to the metamodeler: once again, the one suffers for the sake of the
many. The root cause of needing to output two different languages is of course worth
investigating. Unfortunately, even where there seems little rational call for it, greater
forces may be at work in the form of senior management and stakeholders.
Pages:
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566