Re: [gmt-dev] evolving GMT in a fully open process that allowsothers to

["Jorn Bettin" <jorn.bettin@xxxxxxxxxxxxxxxx>]

> I like this one! I think we should sort out the meta, meta-meta,
> meta-meta-meta confusion. I have the impression that lots of talk about
meta
> models is really about models. Any model in UML that is not about UML, is
a
> model, not a meta model.

Yes! Even beyondUML, *any* meta model is a model in the end ;-)

> Actually, according to this definition, FUUT-je's tool model IS a meta
> model.

Yes.

> It is a model about itself, modeled in its own modeling language that
> is not quite UML. Still, I think it is much more helpful for understanding
> what this model is about, to think of it as a model of what the tool knows
> about, modeled in something close enough to UML that anyone knowing UML
can
> understand it. Since '-je' means: 'Java environment', the model contains
> exactly those things that are helpful to generate Java code and anything
> related (DDL for example or XML), nothing more, nothing less.
>
> I am not in favor to make the tool model very generic, because it would
> loose its applicability to its domain: generating Java applications. What
> would be possible, is to use FUUT-jes tool factory capability to create a
> meta-modeling tool. Or to create a series of specific tools. For example,
> for my PHP/MySQL work, the FUUT-je models I made of the application have
> only limited applicability. Maybe it would be better to create a specific
> PHP tool (using FUUT-je to create it). Such a tool could very efficiently
> generate code from templates. Velocity can easily be used as the template
> engine for such an application, or else the FUUT-je template engine is
> generic enough for this purpose too (with slightly more effort).

With the right generic tool model you can easily generate your Fuut-je tool.

I don't understand why Fuut-je - which as you say is Java specific, and
which has additional idiocyncracies that could be removed - should be at the
root of the tool ancestry. We should strive for good separation of concerns
between problem space and solution space. The dependencies on the target
language (Java in this case) should be kept in template code as far as
possible, rather than in the structure of the model from which you generate.

See my other email. Starting from one meta model of a DSL expressed in some
tool model, you may want to generate multiple modelling tools for the DSL.
One such modelling tool *may be* implemented in Java.

Jorn

Jorn Bettin
jorn.bettin@xxxxxxxxxxxxxxxx
www.softmetaware.com
Tel  +64 9 372 3073 | Mobile +64 27 448 3507 | Fax +64 9 372 3534