I have nothing pending for RC1 so go for +3 whenever you're ready.

    Regards

        Ed

i.e. can we configure our

N-build to use the most recent of EMF's R/S/I/N
I-build to use the most recent of EMF's R/S/I
S-build to use the most recent of EMF's R/S
R-build to use the most recent of EMF's R

?

    Regards

        Ed

Everything is in master for RC1.

I've done the Orbit final R location change.

    Regards

        Ed

Interesting discussion. Please, correct me when appropriate.

Cheers,
Adolfo.
On 08/05/2013 10:12, Ed Willink wrote:

Hi Adolfo

The lack of UML alignment/incomplete auto-generation of the Pivot model
is causing me more and more problems, so it is coming to the top of my
list of things to think about (but not do till M1).

*The easy problem.*

e.g. NamedElement is realized by EMF as NamedElement and
NamedElementImpl with EObject support.

To support arbitrary models DomainNamedElement is manually implemented
with 'the same' interface as NamedElement but without any of the EObject
overheads. The extension of DomainNamedElement by NamedElement is a
one-time manual edit.

Auto-generation of DomainNamedElement is a relatively simple job for an
Acceleo template.

*The hard problem.*

The manual edits of e.g. DomainNamedElement have introduced some
different/better names. Usage of these different names causes type
casting trouble for the CG. The differences must go, so what is better?

Consider UML::Class::ownedAttribute.

This is a singular name for a plural concept and so reads badly in OCL
expressions. MDT/UML2's genmodel has an option to pluralize such names
so that Java users get to call getOwnedAttributes(). [The singular only
makes sense to XML readers; not an important community.]

It is not an Attribute; UML 2.0 rationalized things as Property.

"owned" is an implementation detail and in some contexts there is an
implementation subtlety between "parameter" and "ownedParameter". So
"owned" could be eliminated.

giving OCL::Class::properties

But sometimes the qualifying adjective is helpful. For instance, the
opposite of ownedAttribute is Property::owningType, which is importantly
distinct from Property::type.

Requiring all names to have role adjectives would require Property::type
to be renamed as selfType/elementType/myType/propertyType - all unpleasant.

So perhaps better names are

simple and pluralized for the primary use; type, properties
qualified for secondary usages; owningType, referredProperty

Also we need unambiguously scoped names

Class::properties; all properties in this class and any classes merged
into it
Class::allProperties; all properties in this class and all its
superclasses and any classes merged into them
Class::localProperties; all properties in this class but not any classes
merged into it
Class::allLocalProperties; all properties in this class and all its
superclasses but not any classes merged into them

Class::superClasses; all immediate superclasses of this class and any
classes merged into it
Class::allProperSuperClasses; all superclasses of this class and any
classes merged into it (excluding self)
Class::allSuperClasses; all superclasses of this class and any classes
merged into it (including self)

*The hard decision.*

I've been putting this off for too long and as a result there is a mix
of UML and 'better' names.

1) As close to UML as possible

e.g. Class::ownedAttribute
+ UML model comments can be reused by OCL specification auto-generation
with minimal review
+ OCL reflection is familiar

2) A sensible minor rationalization of UML naming

e.g. Class::properties
+ names can be pluralized
+ names can be more consistent
+ scoped names can be more consistent
+ UML naming is not imposed on implementers of the Domain interfaces

The OCL specification has a couple of constraints that use reflection
and UML names. These are currently illegal, so I don't see that the
existing specifications restrict the design choice.

Note that this only affects OCL/QVT users if they use reflection, so in

umlObject.oclType().properties.type.allInstances().ownedAttribute

oclType() goes reflective so that OCL::Class::properties is used to
access the properties. Then allInstances() instantiates so that
UML::Class::ownedAttribute is used to access properties in the user's
UML model.

This is a slightly perverse example, but highlights the question. Is it
helpful for user's to be aware that reflection takes them into the
tooling domain, or is it better to hide it?

umlObject.oclType().ownedAttribute.type.allInstances().ownedAttribute

leaves the user unaware that both OCL::Class::ownedAttribute and
UML::Class::ownedAttribute are in use.

I really can't decide between alignment and sensible. Do you have any
strong views/insight?

     Regards

         Ed

_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev

Eclipse OCL M7 done and announced.

I've also announced QVTo M7 in the newsgroups.

P.S: Only some comments in OCL M7 N&N are missing.

Cheers,
Adolfo.

Hi Adolfo

All go for OCL Tools.

     Regards

         Ed
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev

All go for OCL Tools.

    Regards

        Ed

I've taken a shot at defining what Thread Safety means for Eclipse OCL in:

http://wiki.eclipse.org/MDT/OCL/FAQ#OCL_Thread_Safety

Comments welcome.

    Regards

        Ed Willink

I didn't set that and I'm not aware of how is the way to proceed to
change that. What about asking in to the modeling PMC ?

Cheers,
Adolfo.

Regards

Ed

_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev