> for things like that, I would consider looking into the SmaCC visitor > automatic generation. From an grammar, SmaCC creates the class, respecting > an eventual inheritance constraint you specify, adds the instance variables, > and generates the visitor (and an equality test too).
Nice. Will have a look. Thanks. > Regarding state machines generation, what class of automatons are you > looking at? Because I'm looking at automatons generation by reusing SmaCC > (for a tentative hardware architecture subject). We have some domain specific objects, for example investment instructions, that go through some domain specific state transitions. It is not enormous, but a state transition model helps to understand what valid transitions there are. As a simplistic example, when we receive an investment instruction, one user "submits" the instruction, another "authorises". From there it moves into a processing state and then complete when the investment is placed. What will be nice is to set up guards on transitions, entry / exit actions and more nice things that can be done with a state machine. Reading the state machine then gives a nice overview of the logic. What will be nice is to see that in the form of a graph, with all the annotations. We do not currently use complexities like concurrency and nesting, but have seen that working before. Does this answer what you're asking? > > Regards, > > Thierry > > > Le 18/10/2016 à 10:01, Otto Behrens a écrit : >> >> +1 for the visitor. What would be nice is to generate methods in the >> form #visit<Class Name>: for all classes in a given hierarchy (eg >> Magritte's MAVisitor). The default implementation of such a method >> would be to call #visit<My Super Class name>: >> >> We have been using state machines for a long time and have built >> generators for it (on a previous project, for which I do not have the >> code). I still think that is a useful idea. It is difficult for the >> code generator to maintain changes in the generated code with changes >> in the "spec". Will you then define a DSL for the state machine? >> >> On Tue, Oct 18, 2016 at 9:29 AM, Julien Delplanque <jul...@tamere.eu> >> wrote: >>> >>> Hello, >>> >>> A generator for the visitor design pattern: >>> - Generate methods in visited objects: VisitedObject>>#accept: (with the >>> selector name configurable) >>> - Generate empty methods (or methods with a "self subclassResponsability" >>> if >>> an abstract visitor is generated) >>> called in #accept: methods of VisitedObjects in the Visitor i.e >>> Visitor>>#acceptVisitedObject: (with the selector >>> name configurable again). >>> >>> Each time this design pattern has to be used, it is annoying to write by >>> hand all these methods. >>> >>> Regards, >>> >>> Julien >>> >>> >>> On 18/10/16 07:24, Hernán Morales Durand wrote: >>>> >>>> >>>> Hi guys, >>>> >>>> I am writing a code generator, doing a few iterations right now. >>>> I want your opinion, which most useful thing would you like to be >>>> generated >>>> automatically? It could be a pattern, an idiom, another language... >>>> >>>> For example my own wish (roadmap) list: >>>> >>>> - A "settings framework" settings class generator. >>>> - A state machine generator (based in the excellent paper of Trevor P. >>>> Hopkins) >>>> - A Spec UI generator. >>>> >>>> Let me know your thoughts. >>>> >>>> Cheers, >>>> >>>> Hernán >>>> >>> >>> >> >> > >
