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  abczy?ski is currently offline Tomasz abczy?skiFriend
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: 7665
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: Tue Jul 16 04:27:15 GMT 2024

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

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

Back to the top