Eclipse Community Forums: Papyrus » Difference between PrimitiveType and <EPackage,ModelLibrary

Help

Home

Home » Modeling » Papyrus » Difference between PrimitiveType and <EPackage,ModelLibrary > EDataType

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

Difference between PrimitiveType and <EPackage,ModelLibrary > EDataType [message #1834663]

Sun, 15 November 2020 00:30

John Henbergs

Messages: 239
Registered: October 2020

Senior Member

Hello,

So I am creating a UML profile with Papyrus and I was advised to use PrimitiveType from the Palette.

Let's say I have a property "phone_number", which will be an integer. What is the difference if I create a PrimitiveType and name it INT and on Properties -> Type -> MyPackageName -> INT,

or if I select it from the Properties -> Type -> <EPackage,ModelLibrary > PrimitiveTypes ->. EDataType Integer.

My end goal is to generate an Xtext grammar for this UML profile. What would be some benefits of each approach?

Thank you!

Report message to a moderator

Re: Difference between PrimitiveType and <EPackage,ModelLibrary > EDataType [message #1834668 is a reply to message #1834663]

Sun, 15 November 2020 12:05

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

Hi

It depends whether you want tooling to understand the semantics of "INT" such as may-be-zero, can-be-added, cannot divide-by-zero ....

By default you have nothing, not even a defined storage. If you map the Ecore implementation to java.lang.int you get some functionality.

Tools know about the Integer, they know nothing of INT. To remedy this Eclipse OCL provides the OCLforUML profile so that you can apply an Integer/Real/... stereotype to your novelty.

You can also define your own PrimitiveType named Integer. Whether this is or is not the same type as a built-in PrimitiveType named Integer is unclear. Eclipse OCL clarifies by specifying that the package hierarchy of Primitive/Tuple/Collection/Map/Lambda types is to be ignored when determining a singleton type for each such potential ambiguity.

Regards

Ed Willink

Report message to a moderator