RE: Automatic conversion



RE: Automatic conversion

From: D H. Akehurst ^lt;D.H.Akehurst@kent.ac.uk>
Date: Fri 10 Mar 2006 - 16:58:56 GMT
Message-ID: <A97ADB9E8A23214492A613C7EC1CAF7B3C0B2B@dogsbody.ee.kent.ac.uk>
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 "."

   self.prop1.prop2.prop3

is neater and easier to read than

   self.prop1->collect(x|x.prop2)->collect(x|x.prop3)

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: puml-list-request@cs.york.ac.uk 
> [mailto:puml-list-request@cs.york.ac.uk] 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 
> interpretation
> of the model and may even point to a multiplicity error in 
> the class model.
> Or am I missing something in the discussion ...
> 
> 
> Robert
> 
> >===== Original Message From Steffen Zschaler 
> <sz9@inf.tu-dresden.de> =====
> >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 
> essentially
> >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,
> >
> >Steffen
> >
> >--
> >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 
> puml-list-request@cs.york.ac.uk
> >with a message containing the word "unsubscribe".
> 
> 
> 
> 
> 
> To remove yourself from this list please mail 
> puml-list-request@cs.york.ac.uk
> with a message containing the word "unsubscribe".
> 
> 
Received on Fri Mar 10 16:59:41 2006