thomas at mail630.gsfc.nasa.gov
Thu Mar 27 13:27:13 UTC 2003
On Thursday 27 March 2003 04:01 pm, Jonathan wrote:
> On Tue, 25 Mar 2003, Brian Thomas wrote:
> > CVS commit by thomas:
> > Added this class to the project as a means for code generators to
> > reuse common code that will summarize important aspects of classifiers,
> > tasks such as finding all the owned classfiers in association with the
> > current classifier, whether or not its an interface or class, and any
> > static attributes, etc are in this class. More methods should be added as
> > utility is recognized. Because this is forseen to only be used by code
> > generators, I have placed it along side of them in the codegenerators
> > sub-directory..appropriate?
> All looks good with the new cppwriter stuff Brian. Well done.
> The Abstract Class header which gets printed out on Interfaces might need
> to be i18n()ed I'm not sure. Maybe a separate headers/ file could be
Hum. Feeling lazy just now. Im not sure where that change would go, if you
see a quick way to punch it into the code, please do so.
Overall I had forgot about internationalization of output text (well, you know Im an
American, so "unilateralism" is a common philosophy over here). Could there
be other spots in the various writers that need the i18n() call on them? I also still
think it a good idea to be more flexible about line ending characters (\n vs \r vs \n\r)
as code generated might be slated to run on a non-UNIX platform.
Speaking of code generators, Im in the middle of a re-design of the code generation
system. I cant figure out if it is better to integrate the ability to specify language specific
parameters within the class diagram dialogs (e.g if you click on a class attribute, and
have code generation set to "CPP" you should have the option of making that attribute
"virtual") OR to have a completely separate interface where the code is edited on (lightly, I
dont want to reinvent kdevelop here!!) and edits saved in a template. The last option what
the basis of my first code generation redesign proposal. Any thoughts on this? How far
should one be allowed to specify the code generation? I had thought that at least being able
to control whether things like auto-generating accessor methods and providing the guts
of operations as a baseline. Having the code editor synced back to the class diagram itself,
so that changes to the class code document propagates back to the original class is a bit
too much to chew at this time. Similarly support for compiling, debuging and fancy editing
(like being able to find/replace snippets of code thoughout a project) are out.
More information about the umbrello-devel