| Re: [OCL] Any plans on parser extensibility, error recovery ? [message #9464] |
Wed, 28 February 2007 14:40  |
Eclipse User |
|
|
|
[Continuing the thread from the now read-only eclipse.modeling.mdt.uml.ocl]
Hi Radek
You may find a slight adaption of the grammars to support extension
for QVT relation in
/cvsroot/technology/org.eclipse.gmt/umlx/plugins/org.eclipse .gmt.umlx.eqvtr.cst
The CVS is currently for OCL 1.1M4.
I have just upgraded to OCL 1.1M5 and am tidying up prior to submitting the
only slightly revised org.eclipse.ocl.internal.parser package in the hope
that with encouragement from us, Christian will find time to incorporate it.
The revision supports grammar extension to realise QVTrelation and introduction
of an ErrorHandler so that custom error handling policies can be supported.
I want my errors to go to IMarker instances so that my meta-model validating
QVTr editor does what you'd expect.
Regards
Ed Willink
Radek Dvorak wrote:
> Hi,
>
> I have few questions on topics that come into play when starting to build
> other tools based on MDT OCL.
>
> 1) OCLparser extensibility
> Other languages built as an extension to OCL (like QVT) could
> benefit from the existing OCL grammar and generated parser and
> provide only those constructs that forms the extension.
> I know that EMFT newsgroup mentions that its OCL parser was not designed
> with extensibility in mind and I am just asking whether this was not
> reconsidered
> with respect to the new M2M project (QVT component).
>
> 2) Error recovery
> Currently, only the fail-fast approach is implemented and there is no
> comprehensive diagnosing
> which accumulates errors encountered during the parsing phase and also by
> the well-formedness
> validation. Reporting these along with the error locations would help a lot
> in development
> of complex OCL expressions.
>
> 3) Debugging (Hooking into EvaluationVisitorImpl)
> There is a post in EMFT newsgroup
> ( http://dev.eclipse.org/newslists/news.eclipse.technology.emf t/msg01547.html)
> on the possibility
> to extend the evaluation visitor.
> The answer here is that "operation calls or property/association-class
> navigation"
> will be provided by the EvaluationEnvironment instead.
> My point is that it would be useful to have a finer-grained hook into the
> evaluation
> process, especially for OCL debugging support needs. In such a case,
> involving something
> like EvaluationVisitor interface seems to me a more suitable alternative to
> be used when implementing
> a DebugEvent aware OCL evaluation (unless debugging is gonna be specially
> handled in MDT OCL itself ;-))).
>
>
> Regards,
> /Radek
>
>
>
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.29829 seconds
Home