Hi
My proposed resolution for http://solitaire.omg.org/browse/QVT13-10.
Regards
Ed Willink
In 8.1.14 delete
Another mechanism is defined to make the type system more
flexible. The typedef mechanism allows attaching additional
constraints to an existing type within a specific context. It
also serves to define aliases to complex data types. When used
in the signature of a mapping operation, the typedef
constraints are added to the guard of the mapping operation.
The
condition is expressed within brackets after the type taken as
reference.
typedef TopLevelPackage = Package [container()=null];
typedef AttributeOrOperation = Any [#Attribute or #Operation];
typedef Activity = ActionState[stereotypedBy("Activity")];
The type defined by a typedef is considered to be in the scope
of the model type of the type taken as reference. For
instance, if Package exists in the context of a UML modeltype,
the TopLevelPackage is also considered being defined in
the context of the UML modeltype.
The “#Metaclass” notation - respectively '##Metaclass’ - is a
shorthand for isKindOf(Metaclass) - respectively
isTypeOf(Metaclass).
and replace
A typedef can also be used to simply define an alias to a
complex type, as for tuple types:
by
A typedef can be used to define an alias for a complex type
such as a tuple type:
In 8.2.2.22 replace
Figure 8.11 depicts the four new types, which are:
TemplateParameterType, Typedef, DictionaryType, and ListType.
by
Figure 8.11 depicts the four new types, which are:
TemplateParameterType, Typedef (deprecated), DictionaryType,
and ListType.
Replace the whole of 8.2.2.23 Typedef by
8.2.2.23 Typedef (deprecated)
The Typedef class was underspecified and unnecessary.
A type alias may be defined by using a typedef
construct.
A Constrained Type may be defined by adding an invariant to a
derived class.
Superclasses
Class
Associations
base : Type [1]
condition : OclExpression [0..1] {composes}
In 8.4.7 replace
8.4.7.1 Syntax for module definitions
by
// Syntax for module definitions
Replace
// typedefs
<typedef> ::= 'typedef' <identifier> '='
<typespec> (typedef_condition)? ';'
<typedef_condition> ::= '[' <_expression_> ']'
by
<typedef> ::= 'typedef' <identifier> '='
<typespec> ';'
and add
8.4.7.1 Deprecated syntax
The following alternative constructs may be provided by tools
offering backward compatibility to earlier versions of the QVT
specification.
// typedefs
<typedef> ::= 'typedef' <identifier> '='
<typespec> (typedef_condition)? ';'
<typedef_condition> ::= '[' <_expression_> ']'
On 09/10/2015 13:34, Adolfo
Sanchez-Barbudo Herrera wrote:
Well,
I'm in favor of deprecating now as part of this resolution. Remove
later (in QVT 2.0).
Regards,
Adolfo.
On 09/10/2015 13:30, Ed Willink
wrote:
Hi
I'm happy with a Tag recommendation rather than
Module::ownedTypedefs.
The only real issue is whether to deprecate or remove Typedef.
Removing it because Eclipse QVTo doesn't implement it isn't a
good enough reason.
But since a Typedef alias is NOT a type and a constrained type
typedef has undefined semantics, I think it can be removed.
Regards
Ed Willink
On 09/10/2015 13:01, Adolfo
Sanchez-Barbudo Herrera wrote:
Hi Ed,
Thanks. I like the clear exposition. Some comments:
a) Sounds Ok, but there is also concept of predefined "alias"
tag, which might lead to deprecate entirely typedefs at all
(NB Module::ownedTypedefs would not be required. I don't
generally welcome messing the AS for the sole AS2CS purpose).
c) Sounds Ok. (not just Complete OCL, QVTo has queries/helpes
!!).
b) Sounds reasonable, but I find it as useful shorthand of a
constrained type (and actually current QVTo grammar doesn't
allow to express invariants, another issue though). In any
case the usage is justified, because original meta-models
didn't have those those constrained types, so you are somehow
extending the involved meta-models with something that the
original one didn't provide. This goal perfectly the fits the
purpose of intermediate data.
I was wondering... what about having these typedefs being
modelled as intermediate classes for c). As intermediate data,
it's responsible of the transformation designer to create
objects conforming to them to be usefully used across the
transformation, and of course they can't be part of the
outputs. We would still require Module::typedefs
(cross-reference rather than a composite one, the types should
be owned by the intermediate package) to identify which
intermediate data are these typedefs definitions (for AS2CS
purposes).
Pros:
+ The concept and the concrete syntax (which I consider
useful) is retained. Otherwise, we might break QVTo (well it
didn't work in Eclipse QVTo, anyway)
+ Typedef is a kinda local type definition for the
transformation (NB be careful with data types. I.e if the base
type is a data type, so should be the extension). The same as
the intermediate data was conceived for.
Cons:
- I don't like Module::typedefs, just for the sole purpose of
a AS2CS translation.
- Providing we could constraint DataTypes, for consistency we
should support "intermediate datatype" definitions, even if
the only difference in the AS is creating a DataType rather
than a Class.
- Intermediate classes/datatypes doesn't make sense for
aliases.
My final position on this is the following:
I like the shorthand (e.g. typedef Activity =
ActionState[stereotypedBy("Activity")];), but providing that
- I don't like Module::typedefs for the sole purpose of AS2CS.
- predefined tags, can replace the other useful typedef usage
(i.e. a) )
- and also, typedefs are not supported by Eclipse QVTo (the
only active QVTo impl is currently active, AFAIK)
I'm inclined to deprecate the entire typedef construct (to be
removed in the QVT 2.0), and force transformation designers to
explicit use tags or intermediate classes to give support to
the use cases that typedef provided. That said, to completely
replace the typedef construct, QVTo would require to allow
define intermediate datatypes and invariants.
Regards,
Adolfo.
On 09/10/2015 10:08, Ed Willink
wrote:
Hi
There are three kinds of typedef.
a) Concrete Syntax alias
typedef MyType = Tuple{....}
saving you the effort of typing Tuple{....} many times. This
is syntax sugar, it does not introduce a new type and so it
should be eliminated by the CS2AS conversion.
This does not appear to be supported by Eclipse QVTo.
It might be useful to support typedef in AS2CS, so it may be
appropriate for an AS 'trace' of the alias in the form of an
AS Typedef instance.
I propose to add Module::ownedTypedefs : TypedElement[*] to
persist the name=>type mappings lost in the CS2AS
conversion.
b) Constrained type
typedef Employee = Person[employer <> null];
Introducing a 'new type' without defining any of its
conformance semantics.
This does not appear to be supported by Eclipse QVTo.
I see no advantage in this over something vaguely like
class Employee extends Person
{
invariant employer <> null;
}
which is standard UML with correspondingly standard
semantics. The latter is clearly a type, the former is
arguably a role; an interesting possibility but one that
needs substantial specification.
I propose to deprecate this form of typedef.
c) Internal type alias
Used to add operations to the standard library.
This is an internal facility which ignores Complete OCL and
the real problem.
The resolution is simple:
In 8.2.2.24 Typedef delete
This is specifically used in the QVT standard
library to attach operations to pre-defined
primitive types, like String and Collections.
Eclipse QVTo can continue to do whatever it likes
internally.
---
Since "typedef" is not supported by the Eclipse QVTo
parser, these changes should cause no problems. Trimming
"typedef" to something useful might motivate its
implementation.
With the Typedef AS class no longer mentioned in the QVTo
spec, Eclipse QVTo can continue to use it as part of its
library definition until OCL 3.0 / the Pivot provides an
extensible mechanism.
Regards
Ed
On 09/10/2015 09:16,
Christopher Gerking wrote:
Hi,
I like intermediate classes, but I've never used any 'typedef' keyword in the CS.
Are these the same concepts at AS level?
Regards
Christopher
-----Ursprüngliche Nachricht-----
Von: qvto-dev-bounces@xxxxxxxxxxx [mailto:qvto-dev-bounces@xxxxxxxxxxx] Im Auftrag von Ed Willink
Gesendet: Dienstag, 6. Oktober 2015 15:08
An: qvto-dev@xxxxxxxxxxx
Betreff: Re: [qvto-dev] QVT 1.3 Typedef issues
Hi
8.1.14
Well clearly you find Typedefs really useful.
Regards
Ed Willink
On 06/10/2015 13:55, Christopher Gerking wrote:
Hi
I'm not yet familiar with typedefs. Could you provide examples for 2) and 3) ?
-----Ursprüngliche Nachricht-----
Von: qvto-dev-bounces@xxxxxxxxxxx
[mailto:qvto-dev-bounces@xxxxxxxxxxx] Im Auftrag von Ed Willink
Gesendet: Montag, 5. Oktober 2015 22:35
An: QVTOML developer mailing list <qvto-dev@xxxxxxxxxxx>
Betreff: [qvto-dev] QVT 1.3 Typedef issues
Hi
Adolfo raised a couple of issues that question the integrity of typedef in QVTo.
1) The Constrained Typedef seems to be an underspecified QVTo-specific syntax bloat that could be handled in a general UML-specified way by a Class with an invariant.
2) The added operations library type typedef seems to be an irrelevant SmartQVT implementation detail that conflicts with Complete OCL.
3) Only the textual type synonym has integrity and utility.
Is it going to cause a problem if 2) is deleted completely, 1) is strongly deprecated with the Typedef AS class shrinking to an Element subclass that persists the textual macro for 3).
Regards
Ed Willink
_______________________________________________
qvto-dev mailing list
qvto-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/qvto-dev
_______________________________________________
qvto-dev mailing list
qvto-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/qvto-dev
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.6140 / Virus Database: 4435/10768 - Release Date:
10/06/15
_______________________________________________
qvto-dev mailing list
qvto-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/qvto-dev
_______________________________________________
qvto-dev mailing list
qvto-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/qvto-dev
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.6140 / Virus Database: 4435/10783 - Release Date: 10/08/15
_______________________________________________
qvto-dev mailing list
qvto-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/qvto-dev
_______________________________________________
qvto-dev mailing list
qvto-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/qvto-dev
No virus
found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.6140 / Virus Database: 4435/10783 - Release
Date: 10/08/15
_______________________________________________
qvto-dev mailing list
qvto-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/qvto-dev
_______________________________________________
qvto-dev mailing list
qvto-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/qvto-dev
No virus
found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.6140 / Virus Database: 4435/10783 - Release
Date: 10/08/15
|