Hi Pete, Pete Rivett wrote:
>Hi Thomas, >I appreciate the trouble you've taken to evaluate OCL, and think several >of the issues are worthy of consideration. >Just for your information, and for others on this list, the latest >version of the OCL 2.0 submission is 1.6 (as opposed to 1.0 you reviewed >which is 2.5 years old!). This is due to be adopted later today, as it >happens. > I reviewed the version I did because it was the one passed around (or referred to with a URL, I forget which) recently by HL7...Can you provide a URL to the latest submission? >Despite the imminent adoption it is still possible to submit issues to >OMG's Finalization Task Force which is responsible for considering >implementation and other issues prior to the standard becoming >officially 'Finalized' and 'Available'. To do this just send an email to >issues at omg.org, or fill in the form at the OMG web site >http://www.omg.org/technology/issuesform.htm. > I guess I could do this, but I don't imagine they are going to be interested in anything but tiny details by now... >In general OMG attempts to be an open and responsive organization and >anyone (not only members) can raise issues against any OMG >specification. Though OMG can only address issues if it know about them >- so I would sincerely encourage people to use the mechanisms available. > my general impression of the OMG, and experience with members of HDTF certainly supports, this, and I think that OMG is overall an organisation with good process, timeliness, and a good track record....in a way it is a pity that HDTF (health domain task force) has little support at the moment (or so I've been told) since the OMG process is definitely superior to that in other standards organisations. But - that's a conversatino for another day/mailing list! >However, while I must admit a bias as one of the submitters of OCL 2.0, >I would disagree that the semantics are 'quite broken'. I assume the >following from the review is intended to illustrate 'broken semantics': >---> >In section 2.5.4, subsection "Navigation over Associations with >Multiplicity Zero or One" it is stated that "...a single object can be >used as a set as well. It then behaves as if it is a Set containing the >single object...". I had to read this a few times to believe it. While >there is clearly a drive to make everything somehow the same for the >purpose of querying, there is no way a formal type system can be >respected if such liberties are taken - the basis of correct >specifications disappears. There is no way, for example, that >PERSON.manager: PERSON can act as a Set<> if has been specified as a >PERSON - these are two distinct types, and have nothing to do with each >other. " ><--- > yes, this is the major problem I see. It is quite pervasive as well. >I view treating a single object as a set as a convenient implicit 'cast' >operation. Most programming languages have such a thing: e.g. to allow >an Integer to be treated as a Real. > well actually, this capability is not casting, but "type promotion", and only applies (as far as I know) to numeric types to enable infix/prefix arithmetic and relational operator semantics (e.g. "3.0 + 1" and "3.1415926 < 2.171828") to be evaluated. Type promotion of numeric types is quite a specific feature, and is done by compilers, not programmers. Casting on the other hand is almost always a dangerous and bad thing. I can't think of any code where it was justified, where the language itself was not already the problem, e.g. by not having generic classes, the lack of whcih is the main reason for programmers being forced to cast. But the real problem is that turning an Integer into a Real is reasonable: they have almost the same interface. Turning PERSON into SET<PERSON> makes no sense - there are no similarities between the interface of a T and a Set<T> in general. No common programming languages support this natively (I'm sure there is some academic language which does), and if programmers start doing such casts, they will get into serious trouble. Secondly, this feature of OCL seems to prevent simple statements like: context PERSON inv: employer <> null This is the most common kind of statement one wants to make in invariants, pre- and post-conditions. I cannot imagine why it is not available (maybe it is - it wasn't apparent to me in the spec, nor to the authors of another report on OCL which I have seen). >And if really concerned about the >difference OCL has capabilities to distinguish an object from a set. > do you mean the dot and arrow notation? >Finally, with regard to implementability, there are several >implementations of OCL in existence (currently of OCL 1, though OCL 2 >does not introduce any radically new capabilities). These exist in both >commercial products (e.g. BoldSoft, now part of Borland) and >university/research projects (e.g. Kent Modelling Framework - >www.cs.ukc.ac.uk/kmf). > this is good to know. However, I feel it is a real pity to have this problem of Set<T>/T in OCL - I think it's a real error in OCL, especially as the rest of OCL is pretty good, and quite powerful. - thomas beale - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
