Given the following (valid example) example:
concern FMOconstraints in Concerns.Examples
{
filtermodule FM1 {}
filtermodule FM2 {}
superimposition
{
selectors
FM1 = { C | isClassWithName(C, 'x') };
filtermodules
FM1 <- FM1;
constraints
Pre(FM1, FM2);
Pre(FM1, Concerns.Examples.FMOconstrains::FM2);
}
}
This produces elements with the following data:
A CPS concern with the name FMOcontraints with the fully qualified name:
Concerns.Examples.FMOconstraints
A filter module FM1 with fqn:
Concerns.Examples.FMOconstraints.FM1
A filter module FM2 with fqn:
Concerns.Examples.FMOconstraints.FM2
A selector with the name FM1 and fqn:
Concerns.Examples.FMOconstraints.superimposition.FM1
> Part 1: external references
This produces a problem when there's a class with the same fqn as the
CPS concern and the class contains elements with a name FM1 or
FM2. Resulting behavior is uncertain, and therefore incorrect. It will
also hide a filter module called "superimposition", "hide" as in it
doesn't priduce an error.
Besides that issue there is also an inconsitency with the notation to
refer to external filter modules:
Concerns.Examples.FMOconstrains::FM2
to refer to:
Concerns.Examples.FMOconstrains.FM2
It would be better to adopt a single notation to refer to CPS concern
elements. That brings us to an additional issue. What are all referable
concern elements, or at least, what is visible? In the current
implementation only filter modules can be referenced from other CPS
concerns. However, the language contains constructions to refer to
selectors from a different CPS concern. But this like it works by means
of a dirty hack instead of a proper notation. For example the following:
Concerns.Examples.FMOconstraints::FM1
would either point to the filter module or to the selector depending on
the context. Within a CPS concern there are three scopes for names:
- filter module names
- superimposition selector names
- superimposition condition names
The two superimposition scopes are structurally placed under the
Concerns.Examples.FMOconstraints.superimposition qualified name, but
still refered to from Concerns.Examples.FMOconstraints::<name>
So between these three scopes there is a naming conflict.
The ARM does not cover external references at all.
So, there are the following issues:
1) concern element naming convention
Internally compose* uses periods as delimiter for everything
(namespaces, type, field, methods) despite the delimiter the
target language uses. Using a period as delimiter for CPS concern
elements can create conflicts with type members. The :: is already
used to refer to filter modules from other concerns, so using that
is a viable option.
2) what are the visible concern elements
- filter modules (a yes obviously)
- superimposition selectors?
- superimposition conditions?
- filter module elements (like conditions)?
a condition from a filter module could be used in the
superimposition and conditional. But this can create a chicken-egg
conflict when combined with filter module parameters.
I think the elements of filter modules and superimposition are like
local variables and should therefore not be publicly visible.
3) filter module and superimposition element naming scopes
this issue depends on issue #2, you obviously should not have
different elements with the same names.
> Part 2: filter module order constraints
How are they actually supposed to work? Vinkes' thesis is not clear on
this subject. It does not dictate any meaning on the scope of the
ordering. Should you be able to define constaints on externally
referenced filter modules (like the second containt in the example) or
should you only be able to define contraints for the local filter
modules (the first constraint)?.
The current implementation is broken because it doesn't expand the local
names and I'm not sure if it completely accepts external references.
According to Vinkes' thesis external references should be
allowed. However, FILTH only seems to work on filter module name rather
than the fully qualified name, which is kind of useless when there are
multiple filter modules with identical names in different concerns.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Composestar-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/composestar-developers
