structuring and reusing generators
Printed From: MetaCase
Category:
Forum Name: MetaEdit+
Forum Description: All topics relating to MetaEdit+ or DSM
URL: https://www.metacase.com/forums/forum_posts.asp?TID=147
Printed Date: 27.Mar.2026 at 02:01
Software Version: Web Wiz Forums 12.05 - http://www.webwizforums.com
Topic: structuring and reusing generators
Posted By: petri
Subject: structuring and reusing generators
Date Posted: 03.Jun.2010 at 18:11
|
Hello,
How would you recommend structuring the generators within MetaEdit for maximum modularity and reuse? I find it that the number and size of generators easily grows fairly large. This has an adverse effect on manageability and efficiency of developing and updating them. Being able to modularize them, thus reducing size, and storing them in different logical places (modules or packages) would help there. I tried checking the forum the book of Kelly & Tolvanen, but did not find much on this topic. Or maybe I am approaching this from a wrong angle? I did find out that on the surface, it seems it is possible to establish sort of modular structure of generators, by placing all generators specific to a purpose into its own graph, and running them as subgenerators as needed. Apparently however, it is only possible to run generators associated within the same graph, and its parent graphs. Referring to generators outside graph's inheritance chain seems to be valid MERL, but trying to run such a generator results in an error. Thus for the idea to work, one has to establish a somewhat artificial graph inheritance chain to be able to structure generators in different graphs for modularity and reuse. This is quite restrictive, given there is no multiple inheritance. So how would you propose structuring the generators when there are a large number of them? Say, when there's a for example from a dozen to three-four dozen generators per each of: - translators etc. utilities - building & packaging (folders, files, building) - generating code using a DSL for platform 1 - code for platform 2 (same DSL) - likewise for platform 3 (still same DSL) - documentation - tests Thanks. |
Replies:
Posted By: stevek
Date Posted: 03.Jun.2010 at 19:24
I suppose our implicit advice is embedded in the existing generators, particularly the ones that are sizeable and deal with multiple platforms, such as the Digital Watch example. Of course that advice has a couple of provisos: some of the generators are old, so may not do things in the best way today; and there's always room for "do what I say, not what I do"  .
The main structure we use is indeed the graph type; that's the only real equivalent of a module. Actually, it's more like a class, in that a call to a generator will look up its definition in the current graph type or any of its supertypes. Using the graph type enables us to offer the IDE features of the Generator Editor, e.g. the available object types and their properties.
Another IDE feature is the call tree hierarchy. We calculate which generators call other generators via static analysis, including calls to generators whose names are formed dynamically, or to generators in other graph types. From that we find all top-level generators, and show the call tree hierarchy down from them. When we implemented that I was amazed at how well it worked: the previous simple alphabetical list of all generators turned into a tree that showed the structure clearly and concisely - even though we hadn't written our generators to fit in well with that approach.
My experience is that in a single graph type, the current structure copes well at least up to about 100 generators. I've never added extra graph types just to get a separate place to store generators, but as you say that would be a fairly blunt instrument for attacking the problem. Since you apparently have anything from 100 to several hundred generators, I'd be interested to take a look at what you've got: I could make some suggestions for how to structure what you have now to best use the existing tools, and get ideas for possible future improvements.
|
Posted By: stevek
Date Posted: 05.Jun.2010 at 18:50
|
A couple more things came to mind: You can use dynamic dispatch by building up the name of the sub-generator to call. At its simplest this is just including the name of a type in the generator names, e.g. _UI_Button, _UI_Menu etc., and then calling with subreport '_UI_' type run.
Getting more advanced, you can achieve dynamic dispatch based on multiple factors. For instance, you can use variables to pick which language or platform you are generating from, e.g. _UI_Java_Swing_Button, and call subreport '_UI_' $lang '_' $platform '_' type run. If most cases have a default, e.g. the same code for most platforms, you can first call _UI_Button and have that check the $platform variable and either do the default or re-dispatch as necessary.
You can make generators parameterizable by using variables. Setting the variables before calling is then the equivalent of passing arguments. You can get the equivalent of a function return value by having a particular variable that is set by the sub-generator. An alternative would be to wrap the call in a variable..write..close block, which will catch the output. Obviously, these "functions" are non-reentrant and non-recursive, but then MERL isn't really intended for implementing your own functional language
.For readers less familiar with MERL: Before you move on to this more advanced approaches, though, make sure you have a good feel for http://www.metacase.com/support/45/manuals/mwb/Mw-5_3_1.html - MERL's normal approach . The strong focus on output streams, navigation and the stack make using MERL rather different from using standard 3GLs; they are also what make MERL better at its task than standard 3GLs would be.
|