Re: [cme-dev] Composition and Query Language

[Harold Ossher <ossher@xxxxxxxxxx>]

Peri wrote on 07/21/2004 06:12:21 PM:

> Harold, I've had a look through this,
Thanks for the very speedy response, Peri! Some quick responses of mine
are below, but much more discussion among us is needed - this is
just some initial thoughts to start the ball rolling, and your concerns,
and others', might well lead to a rather different solution.

> but I'm hampered by not
> understanding the intended use(s) of this composition language.
It's intended as Hyper/J2, for people to do the sort of things
they did (or wished they could do) with Hyper/J, as well as extraction,
which I haven't addressed yet and forgot to mention. Most immediately,
to lead to something Juri and Thomas can use in their book to describe
compositions. The language is couched in terms of composition
relationships,
because I imagine it's being used in the context of ConMan, either
textually
driven or via a UI. The relationships can be created in a concern model,
and
interpreted by the CCC builder.

> It
> looks as though it's intended as a general-purpose, compile-time
> composition notation (unless I missed the provision for dynamic).
>  First, is this the case?
Yes. There is no specific provision for dynamic. I'm don't see offhand
that it can't be used for dynamic composition of classes, given a
dynamic compositor and reload capability, but it certainly doesn't
address issues of instance-based composition.

> Second, is this the best approach to take
> (versus, for example, a set of smaller composition languages that
> address subsets of activities but provide higher-level constructs
> that are easier for people to use--a DSL-ish sort of approach--and
> translate down to CCC, where we have PlainWay for the lowest-level
> and most powerful language)?
I agree that the DSL-ish approach is very attractive, and made brief
mention
of it in the draft. Most of the draft actually describes a model rather
than
a particular language, and my belief is that an evolution of that model
will
andits support will help with imlpementation of DSLs on CCC: it provides a
layer on CCC that supports definition and interpretation of "higher-level"
concepts in an open-ended way.

> (I'm moderately concerned about what
> it would take to do "hello world" here :-).)
I hope this would be really easy, like
      merge concern (Hello, World) as HelloWorld
That's all the user should need to say for a very simple case.

> Third, where are you
> assuming the developers are starting (code? design? anywhere?)?
I wasn't making particular assumptions about this. It should work on
anything that CCC can handle. However, the examples I worked through
concretely so far are all derived from Hyper/J.

> And finally, I've missed the relationships (if any were intended)
> between this language and (a) the query language (except for bound
> variables),
There is an non-terminal called <query>, which is intended to represent
a query in any query language, such as Panther. I mentioned bound
variables only to explain the relationship between the several queries
making up a correspondence. The approach is orthogonal to query language,
I believe.

> (b) AspectJ,
I would like to ensure that AspectJ's compositions can be expressed in this
language, with the assumption that an AspectJ-specific pre-processor
performs
the following actions first:
- Transforms advice bodies to methods.
- Generates helper methods and/or combination graphs to deal with dynamic
  residue. These can then be composed in where needed using the composition
  relationships.
- More? (E.g., need something to synthesize "thisJoinPoint"; don't yet know
  how that will work).
It will take some detailed work as this evolves to ensure this can really
be
done.

> and (c) the extraction language.
It's a key requirement this language handle extraction too. I can imagine
an
"extract" relationship, and some special auxiliary attributes to control
things
like reference handling (e.g., declaration completion). The approach in the
draft essentially allows one to bundle CCC convenient sets of CCC
functionality,
and additional processing provided by plugins,
under simple names that the user can just use, and to provide various
options
through similar simple names. When we figure out exactly how to accomplish
extraction with CCC, it should be possible to bundle the necessary controls
and
options in this way. At least, that is my thesis. If I am wrong, then this
approach is deficient and needs to be enhanced or abandoned.

> [from your followup note] Sorry, I missed item (d), the relationship to a
concern model, as well.
I mentioned this briefly above: the composition relationships in this
approach could go into the concern
model, and be interpreted by the builder. And the items found by the
queries would then be concern model
elements. But perhaps there is a deeper connection I am missing...
>
>
> Take offline?  Or should I write up details?
Either or both.
>
>      Peri
Thanks, Harold
>
> Harold Ossher/Watson/IBM@IBMUS
> Sent by: cme-dev-admin@xxxxxxxxxxx
>
> 07/21/2004 05:45 PM
>
> Please respond to
> cme-dev
>
> To
>
> cme-dev@xxxxxxxxxxx
>
> cc
>
> Thomas Stets <stets@xxxxxx>
>
> Subject
>
> Re: [cme-dev] Composition and Query Language
>
> Hi all,
>
> I finally had a chance to get down some thoughts about the composition
> langauge issue. They are very half-baked, and the exposition is very
> hurriedly written, but I hope this is enough to spark discussion.
>
> The examples are all from Juri and Thomas's paper (many thanks!), showing
> how they would be done. As you'll see, the syntax I have used is a little
> different. That's not because I think it reads better - it doesn't - but
> because I was going with a very general, extensible syntax, and did it
> quickly. I'd be interested in comments of all sorts, including how to
> improve the suggested syntax. (I may not be able to respond for a while,
> however).
>
> Thanks, Harold
>
> (See attached file: Composition Language v0.doc)
>
>
>             Juri
Memmert
>             <memmert@jpmdesig
>             n.de>                                                      To
>             Sent by:                  CME
Developers
>             cme-dev-admin@ecl         <cme-dev@xxxxxxxxxxx>
>             ipse.org                                                   cc
>                                       Thomas Stets <stets@xxxxxx>
>                                                                   Subject
>             06/22/2004 05:14          [cme-dev] Composition and Query
>
PM                        Language
>
>
>             Please respond to
>                  cme-dev                                                  
>
>
>
> Hi all,
>
> at http://www.jpmdesign.de/papers/CME_Query_and_Composition_Language.pdf
> you can find a paper a colleague of mine an I wrote on the current query
> language and the to-be-developed composition language for the CME.
> We'd be very happy to discuss this if we came up with something you like
> (or abhor).
>
> Juri
>
> -----
> Desist from enumerating your fowl prior to their emergence from the
> shell.
>
> _______________________________________________
> cme-dev mailing list
> cme-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cme-dev[attachment
> "Composition Language v0.doc" deleted by Peri Tarr/Watson/IBM]