Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [] questions about elements naming strategy and, Collection<?>, EObject, String)

Hi Vincent,

In most cases, I think the default naming makes little sense in real-world models. UML requires NamedElement to have unique names, in a given Namespace, only if their name is non-null.

Users building a real-world model will always give a Name to their elements when they need one. If the element doesn't need a name, then 'null' is a good default (And more efficient than trying to find the next ID increment for each new element)

However, this default naming strategy is still useful when building test/demo/toy models, where the names are required but don't really matter. For such models, performances don't matter either, since they are usually really small (< 100 elements). So having this default naming strategy as an option makes sense, but it shouldn't be there by default.

If there are occurrences where non-null, default names are required, then they should probably be treated specifically (e.g. with dedicated tooling). But I don't think this should be the default for all Papyrus NamedElements, considering the high cost of this strategy.


On Fri, Jan 19, 2018 at 4:56 PM, LORENZO Vincent <vincent.lorenzo@xxxxxx> wrote:

Hello everybody,

                The work about the element’s creation performance has made good progress. I will send an email with our results next week.

To do this work, I look the method, Collection<?>, EObject, String) which is not very efficient.



In this method, there are several things I don’t understand:

                1. Does someone know in which cases we get elements which are not uml.Element in this method ? I found these points :

- references to ENamedElement

                                - instanceof on EObject

                                - calls to org.eclipse.gmf.runtime.emf.core.util.EMFCoreUtil.getName(EObject)  (really useful?)

                               I checked, Table and Diagram creation don’t use this class to be named!


                2. Concerning its parameter “Collection<?> contents”, do you know a usecase where this parameter's value is not the owner’s content of the object to name (got using eContents or another UML method)?


                3. The method crosses all elements of the "contents" parameter to find a unique name with an index. It is not very efficient but it is safe to get a unique name.

                     We think the default name is changed just after the element creation most of the time, so this feature is maybe not so useful to the final user. That’s why we propose to change this behavior:

                               - by default : the increment could be the size of the contents list parameter (it should be unique the most of the time)

                               - a new preference provides the access to the current behavior

                               - another new preference to bypass the incrementation step of the naming process.


                               Please, do you have any suggestions about this point ?



FYI, I attached the concerned class.






CEA Saclay Nano-INNOV



Point Courrier n° 174

91 191 Gif sur Yvette CEDEX


_______________________________________________ mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Camille Letavernier

Senior Software Engineer
EclipseSource France

Phone: +33 1 85 41 09 21

EclipseSource France SAS
7 rue de la Croix Martre
91120 Palaiseau

General Manager: Remi Schnekenburger
Registered Office: 7 rue de la Croix Martre, 91120 Palaiseau, France
Commercial Register 824 977 516  R.C.S. EVRY

Back to the top