Skip to main content

Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » how to reach OCLMessage from OCL API?
how to reach OCLMessage from OCL API? [message #1804883] Tue, 02 April 2019 17:34 Go to next message
Tomasz  Babczynski is currently offline Tomasz BabczynskiFriend
Messages: 11
Registered: May 2015
Junior Member
improving the QFix in Acceleo I used the call:

which is marked as discouraged because it belongs to the internal package of OCL project. I don't feel comfortable with it although I believe that it is better than using just the string of the (localized) message . My question is if it is any possibility to achieve the same effect - to obtain the pattern from the original error message - using API operations?


Tomasz Babczyński
Re: how to reach OCLMessage from OCL API? [message #1804892 is a reply to message #1804883] Tue, 02 April 2019 20:04 Go to previous message
Ed Willink is currently offline Ed WillinkFriend
Messages: 6729
Registered: July 2009
Senior Member

API design is a really hard compromise. If users can access everything, nothing can ever evolve without breaking some obscure usage. But if nothing is exposed, it is a real pain for extenders. Probably best to start narrow and broaden in response to user requests.

In this case I'm inclined to say just suppress the warning since OCL is pretty mature and messages (certainly their symbols names) are unlikely to change. If it does change you would probably like the compilation error to alert you rather than have a silent text mismatch. You could use API reflection but you probably just wrap the warning / silent mismatch hazard up in extra complexity.

I find that some EMF and UML constants are not visible where I need them, so I sometimes create an XXXConstants files where I define clones of the external symbol for use internally. It would be relatively easy to auto-generate an from some build step that has larger dependencies to allow these to be used without requiring them at run-time (e.g. to use a symbolic UML nsURI without any dependency on UML.). This can guarantee no run-time crash with a fall-back if there has been a change.

I think that OCLMessages.bind(...) is an historic relic from when Java support was way behind the Unicode standard; IBM enhancements upgraded by a couple of versions. NLS.bind(...) should do fine these days.


Ed Willink
Previous Topic:Tuple type availability in Acceleo OCL
Next Topic:Safe OCL
Goto Forum:

Current Time: Thu May 28 12:53:58 GMT 2020

Powered by FUDForum. Page generated in 0.01820 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top