[cme-dev] Possible new feature

[Juri Memmert <memmert@xxxxxxxxxxxx>]

Hi,

I just came across a feature that I believe we should offer.

I came across this issue when I defined two concerns that ostensibly
have the the same methods in them but didn't in reality.
I intended the concerns to be used in the same context, one at a time,
offering different but similar services (error handling for end users
vs. error handling and reporting for developers).

I went to great pains to keep both concerns synchronized over the months
of developing the application so that I could eventually use / Hyper/J
or the CME to use two concerns to swap at need.
"Synchronized" in this context means that I implemented all methods /
classes in both concerns so that they would be identical in signature.

Upon pulling the classes / methods into my concern model, I came to
realize that the concerns were not identical in their signatures.

The scope of the problem is more general than that, though.
It could arise in product lines just as easily.
A slightly different take on this is the question whether a set of
concerns actually constitute an executable system or whether there still
are methods that require implementation (or a concern with these methods
added to the system).
I, for my part, would want to know in advance of the build / testing
process whether I missed a method that I thought would be provided by
one of the concerns involved.

I see several possible use cases:

a) Check whether two concerns are "declaratively identical". That
requires the signatures of two concerns to be identical (same classes,
same method signatures).
It assumes that the same composition specification would be used to
merge one of these concerns with an identical set of other concerns. The
result would contain the same classes / methods in terms of their
signature.

b) Check whether two sets of concerns are "declaratively identical".
This would be used when you have two different builds of an application
with different concerns or the same methods partitioned into different
concerns and want to know whether both builds would give the same set of
classes and methods upon build.
This assumes that the same composition specification would be used.

c) Check whether a concern can satisfy the requirements of another
concern (implements all methods required by the other concern). This
assumes that the composition specification is also parsed to identify
all renames / mappings, etc.
I don't know how far through the process of actually merging the two
concerns we would have to go for this.


I hope you have some thoughts on this.


	Juri


-----
Dear Emily: I collected replies to an article I wrote, and now it's time
to summarize. What should I do?
 -- Editor 
Dear Editor: Simply concatenate all the articles together into a big
file and post that. On USENET, this is known as a summary. It lets
people read all the replies without annoying newsreaders getting in the
way. Do the same when summarizing a vote.
 -- Emily
Postnews Answers Your Questions on Netiquette