Eclipse Community Forums: OCL » how to reach OCLMessage from OCL API?

Help

Home

Home » Modeling » OCL » how to reach OCLMessage from OCL API?

Show: Today's Messages :: Show Polls :: Message Navigator

how to reach OCLMessage from OCL API? [message #1804883]

Tue, 02 April 2019 17:34

Tomasz abczy?ski

Messages: 11
Registered: May 2015

Junior Member

Hi,
improving the QFix in Acceleo I used the call:

OCLMessages.bind(OCLMessages.OperationNotFound_ERROR,...

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?

Tomek

Tomasz Babczyński

Report message to a moderator

Re: how to reach OCLMessage from OCL API? [message #1804892 is a reply to message #1804883]

Tue, 02 April 2019 20:04

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

Hi

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 XXXConstants.java 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.

Regards

Ed Willink

Report message to a moderator

Previous Topic:	Tuple type availability in Acceleo OCL
Next Topic:	Safe OCL

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Thu Apr 25 08:47:21 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter