>>>The generators are there to do the grunt work. If the code has a lot of (meta)data in it, tiresome syntax and generally is a nuissance to write, it's about time to write a generator.
>>
>>Perhaps. OOP can address much of that.
>
>Exactly. Hence the reference to obsolescence below.
>
>>>Nowadays, most of this stuff is obsolete - and what generators I still use (and write occasionally) are Intellisense scripts which make my life easier, or write the initial versions of things which I'll edit later. IOW, they just write the default version of code, and I don't run them again. That's like the difference between wizards and builders - these are more like wizards.
>>
>>Obsolete is true! I'm not sure I can call Intellisense or my SnippetFactory a code generator. Maybe generating an big components / entire systems might be considered a code-generator bad practice as it begs for post-generation mods.
>
>The experience with generators, though, gives you some insight into how can an app be expanded by putting scripts into memos. Look at the TaskPane engine in VFP - most of the stuff is XML in memos somewhere, or just XML files on disk, and these can be changed independently of the code. Such code can be generated somewhere and distributed to users - and in case of TaskPane, it can be even downloaded (i.e. "refreshed") behind the scenes.
>
>I agree that the days when it was nice to generate the whole app are gone. There's not so much repetitive code anymore, because the repetitive part was in metadata-to-code part, when all the field names, their on-screen coordinates etc had to be stored in tables somewere, then turned into code. Nowadays we have the code which runs straight from metadata (vcxes, scxes), so we don't need no more stinkin' screen code generators.
>
>>Without suggesting you do this, relying on Intellisense possibly too much instead of good object / UDF design seems bad to me. With Intellisense embedding code snippets, should a problem be discovered in that, one would have to go through much code to repair that problem.
>
>Right, and the good example are the RI code generators. I'm not using it, but I saw how it looks. Which is probably the reason I'm not using it :).
>
>However, there is room for code generation in intellisense - where it save you more time than it takes to check the code generated. My example is pretty much any place in code where you may need a list of fields, or anything that requires some code per field. So I just make sure the correct alias is selected in IDE, I just type the IS shortcut (mostly based on the work of Frank Dietrich, who has a beer from me anytime), and the whole set of commands is generated for each field in the current alias. Then I just delete the ones I don't need. This saves me a lot of time, because the alternative is to have a list of fields in some other window and copy/paste, retype or just try to remember their names.
>
>Another example is when subclassing a prg-based class. I'd rather generate empty code for hooks, so I don't forget some of them, and have the basic properties pre-filled. For a bizobject, for instance, that's any code related to its main table, key field etc. Of course, I edit that later.
>
>>Get GenScrnX and add a plug-in? It's almost unfortunate that MODIFY SCREEN in VFP didn't leave the screens unconverted. If I MODIFY FORM oldscreen I should get a warning to run the converter.
>>
>>However using FPW26 I can modify the screen, generate and run the system in VFP.
>
>Never used GenScrn, really. We had our own generator back in 1989, which had its own metadata (actually pulled stuff from .frm files designed in dBase III, or was it II), and I converted it to FP1.0x, then to 2.0, then rewrote about 98% of it to use FPD2.6 stuff. It didn't generate .spr code as such - never had a READ statement in it. Instead, it generated a set of routines for a form, which were then called by one driver routine which had all the Read, Save Gets, special key interception, status checking etc.
>
>Even had some sort of grid-like thing (read-only, though) which was fast as a snake, had incremental search, reordering by any column, and arbitrary action assigned to special keys. Which was actually generated.

My two cents worth. I suspect that there will come a time in the future when almost all code will be generated and run by a somewhat intelligent computer app that will deduce our needs and generate code to suit those needs. This then is a likely direction for code generation to travel at this time. This ends today's sermon.