Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdt-ocl.dev] Patch for https://bugs.eclipse.org/bugs/show_bug.cgi?id=338376 
Hi Axel
I wouldn't recommend changing the declared API, however you might manage to change only the semantic API by introducing an additional reserved (e.g. "::") path segment, so that existing code just sees a longer path. But you have to review every piece of code that uses the path to see if it is semantically affected. This includes a review of QVTo and Acceleo code which will inherit the changed parser grammar.
As an aid to reviewing you might temporarily introduce the extra methods so that compiler warnings guide to where you need attention.
However: you are modifying code that is hard to modify, an evolved unclear API that must remain compatible with unknown requirements. I think you will find it difficult to achieve what you need and even harder to achieve API compatibility. Avoiding impact on clients is harder still. And with M6 API freeze less than two weeks away, I would have to say no chance. 

     Regards

        Ed

On 04/03/2011 16:40, Axel Uhl wrote:

Hi Adolfo,
I successfully managed to adjust the grammar, introduce a global:Boolean flag on PathNameCS in OCLCST.uml, OCLCST.ecore, re-generate. I added the createPathNameCS(SimpleNameCS, boolean) in AbstractOCLParser and had createPathNameCS(SimpleNameCS) delegate to it, as you suggested. The CST creation seems to work fine based on this.
Now comes the trickier part in AbstractOCLAnalyzer where I have to exploit the global-flag (which, as I can see in the debugger, gets set successfully for a type specification ::ecore::EClassifier). Here, the problem is that methods such as Environment.Lookup.tryLookupClassifier only take a List<String> argument. The PathNameCS is not handed down to, e.g., EcoreEnvironment.lookupClassifier(List<String>).
We'd have to add something like Environment.[Lookup.]tryLookupGlobalClassifier(className) as some sort of a duplication of he tryLookupClassifier, and additionally Environment.lookupGlobalClassifier as a copy of lookupClassifier. Would that be acceptable? 

Best,
-- Axel

On 2/28/2011 7:22 PM, Adolfo Sánchez-Barbudo Herrera wrote:

Axel,

I'll try to explain in some quick steps how to deal with LPG parser
infrastructure. It looks like it doesn't need too much work to do this
enhancement...

1. Launch LPGGenerator: Select OCLParser.g -> Run External Tools (Button
in the tool bar, next to the Run button) -> LPG2 selected file
2. The launch will probably fail :). You need the proper LPG generator
in the workspace. So, I recommend to checkout
lpg.generator.YourOS.YourArch project from LPG SVN (Can't remember
location, look into sourceforge web page:
http://sourceforge.net/projects/lpg/).
3. Add a new parser rule in the EssentialOCL.gi grammar. I think that
the following one should work:
pathNameCS ::= '::' simpleNameCS
/.$BeginCode
...
$EndCode
./
4. You probably will want to make difference at the CST level between
the "normal" pathNameCS and the new variant which distinct the use of



this "global scope". A boolean (startsWithDoubleColon, isGlobal,
whatever you prefer) attribute in PathNameCS class could be useful ->
goto org.eclipse.ocl/model/OCLCST.uml and regenernate OCL.CST ecore +
java classes
5. You will also need to create a new creatPathNameCS method in
AbstractOCLParser, which receives said boolean value. We will need to
maintain (and deprecate) createPathNameCS(SimpleNameCS name) which will
delegate the PathNameCS creation to the new method, passing a 'false' value. 
6. pathNameCS::= ' ::' simpleNameCS
and pathNameCS::= simpleNameCS
will probably call the new method passing respectively 'true' and
'false' values.
7. You will finally need to look into AbstractOCLAnalyzer to exploit and
distinct these variants. It's the more complicated part, but the easier
for you (I mean which doesn't require any extra explanation by me), just
time to code the enhancement.

If you need more help, just make me know it.

P.D: also remember to generate the backtracking parser:
org.eclipse.ocl.parser.backtracking: OCLBacktrackingParser.g
P.D2: not need to remind to create some test cases and such, or ? ;P

Cheers,
Adolfo.
El 28/02/2011 17:22, Adolfo Sánchez-Barbudo Herrera escribió:

Axel,

Without reading anything yet, I must note that I could only help
concercing the LPG parser, I don't I have any idea/read about all the
stuff Ed has built upon xtext-based grammars/editors, pivot, etc...

Cheers,
Adolfo.

El 28/02/2011 12:11, Axel Uhl escribió:

Hi Adolfo,

I know you are very literate when it comes to the existing OCL parser
and the process of changing or extending it. See
https://bugs.eclipse.org/bugs/show_bug.cgi?id=338376 for a request
for which---due to Ed's lack of resources---I'd like to try to
provide a patch. Can you give me instructions for
changing/re-building the parser?

I presume I'd have to change OCLParser.g to introduce the possibility
of a '::' prefix which indicates global scope. Can you roughly point
me at the other things that need to be done (analyzer, any changes to
the CST, ...)?

Thanks and best,
-- Axel



--
Open Canarias, S.L.
    *Adolfo Sánchez-Barbudo Herrera*
adolfosbh(at)opencanarias(dot)com
<mailto:adolfosbh%28at%29opencanarias%28dot%29com>
C/Elías Ramos González, 4, ofc. 304
38001 SANTA CRUZ DE TENERIFE
Tel.: +34 922 240231



--
Open Canarias, S.L.
    *Adolfo Sánchez-Barbudo Herrera*
adolfosbh(at)opencanarias(dot)com
<mailto:adolfosbh%28at%29opencanarias%28dot%29com>
C/Elías Ramos González, 4, ofc. 304
38001 SANTA CRUZ DE TENERIFE
Tel.: +34 922 240231


_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev


-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1204 / Virus Database: 1435/3480 - Release Date: 03/03/11

Back to the top