RE: Automatic conversion
Two responses, if I have understood your point correctly:
1) I don't think it makes tool implementation easier, it actually adds another bit of complexity to the implementation.
2) I think that the coercion certainly makes navigation expressions easier to read and write, particularly with respect to the "."
is neater and easier to read than
I'm not so sure about the coercion for "->"
although it does solve the original problem mentioned, where
self.person->forAll(salary < self.maxSalaryDept)
becomes applicable whether the multiplicity of person is [0..1] or [0..*]
> -----Original Message-----
> From: email@example.com
> [mailto:firstname.lastname@example.org] On Behalf Of france
> Sent: 10 March 2006 16:28
> To: puml-list
> Subject: RE: Automatic conversion
> Like Thomas I'm still somewhat unsure why the two operators
> coerce their
> arguments. It is much cleaner semantically to have "." applied only to
> scalar arguments (without coercion) and the -> to
> collections. The coercion
> adds another
> layer of semantic complexity that I think is uneeded from a
> usability point
> of view (though it may make tool implementation easier -
> interesting trade-off
> here ...). Leaving out the coercion allows modelers to uncover errors
> in multiplicity or in their understanding of constraints and
> models. For
> example, a constraint writer may
> write an expression in which a "." is applied to an
> expression that actually
> evaluates to a collection and the writer
> thought it would evaluate to a scalar value (I'm not
> including multiplicities
> such as 0..1 here since I consider these to be collections).
> Identifying this
> as an error can cause the modeler to pause and rethink their
> of the model and may even point to a multiplicity error in
> the class model.
> Or am I missing something in the discussion ...
> >===== Original Message From Steffen Zschaler
> <email@example.com> =====
> >Hi Thomas,
> >Thomas Baar wrote:
> >> D H. Akehurst wrote:
> >>> You can use the invariant
> >>> context Department inv: self.person->forAll(salary <
> >>> self.maxSalaryDept)
> >>> In the case where the multiplicity is [0..1].
> >>> Using the '->' operator on objects that are not collections
> >>> automatically wraps
> >>> the object in a Set.
> >>> Wraping an undefined value into a set results in an empty
> set, hence
> >>> your expression
> >>> gives true when there are no managers.
> >> Dave,
> >> I'm very puzzled by the automatic conversion to
> collections, it would
> >> mean
> >> that, for example, 5->forAll(x| ...) would be
> syntactically correct!
> >> What would then be the point to have two different
> operators '.' (dot)
> >> and
> >> '->' (arrow) in OCL? So far, it helped the reader to find
> out if the
> >> source
> >> expression is of object or collection type.
> >I don't quite see your problem here. The different operators
> have been
> >introduced specifically to allow for automatic conversion.
> Without such
> >a conversion there would be no need for the operators as the parser
> >would always be able to decide whether the source is a
> collection or not
> >and, thus, whether a.forAll is valid OCL. By using '->' you
> >state that you intend the source to be used as a collection,
> whatever it
> >really is. Conversely, by using '.' you state that you want
> to use the
> >source as a scalar, whatever it really is. This happens, for
> example, in
> >navigation expressions, where ->collect(...) expressions are
> >automatically inserted---even though in the last revision of the
> >standard I couldn't find anything about this anymore.
> >Best regards,
> >Dipl.-Inf. Steffen Zschaler
> >Research Assistant
> >Technische Universitšt Dresden
> >Department of Computer Science
> >Phone +49 351 463 38555
> >Fax +49 351 463 38459
> >Email Steffen.Zschaler@tu-dresden.de
> >WWW http://www.steffen-zschaler.de.vu/
> >To remove yourself from this list please mail
> >with a message containing the word "unsubscribe".
> To remove yourself from this list please mail
> with a message containing the word "unsubscribe".
Received on Fri Mar 10 16:59:41 2006