Re: OCL 2.0 Type Inference



Date view Thread view Subject view Author view Attachment view

From: Alexandre Correa (alc@wnetrj.com.br)
Date: Mon 22 Dec 2003 - 13:47:59 GMT


Hi,

the operation commonSuperType defined on page 3-22 states that the type can 
be "ANY" of the most common supertype of the classifiers. In the example 
given by Brian, the result would be Set{A , B}->any(true), e.g., both A and 
B could be the most common supertype of the classifiers C and D. Comments??

The picture gets more confusing when interfaces are involved, such as in 
the example below:

A is a subclass of S1
B is a subclass of S2
A realizes interface I1
B realizes interface I1

Let a : A and b : B
what would be the type of the collection literal: Set {a, b} ?   OclAny or 
I1?
I think it would be I1, since I1 conforms to OclAny.
Comments??


Regards,
Alexandre Correa
Federal University of Rio de Janeiro


At 02:41 22/12/2003 -0800, you wrote:
>Hello,
>
>1. Since both A,B are supertypes of C,D, we can't choose either of them
>    as common supertype, so the answer should be OclAny, making the type of
>    Sequence{c,d} Sequence(OclAny).
>
>2. 3. 4. If Sequence{c,d} has the type Sequence(OclAny) then the iterator
>          v has the type OclAny. Since OclAny.a and OclAny.b do not exist
>          any compiler should stop here with a feature not found message.
>          Since we have a compilation error I don't think we should talk about
>          the expression being undefined. It is simply semantically incorect.
>
>I couldn't find relevant information in the specification to support 1.
>The collection literals section present only integer and string collections.
>If anyone knows about such information (something formal about how the type
>of a collection literal is determined in this case) somewhere else please
>point it to us.
>
>Best regards,
>Adrian
>
> > Hi,
> >
> > I have some questions about type inference in OCL 2.0. If possible, please
> > point
> > me to the relevent part of the specification (PTC/03-10-14 or a later
> > version).
> >
> > Consider these classes:
> >
> >      Class A { a : Integer }
> >      Class B { b : Integer }
> >      Class C subclasses A, B
> >      Class D subclasses A, B {
> >          cd(c : C, d : D) : Sequence(Integer)
> >      }
> >
> > And this set of postconditions (please ignore the fact that they are
> > inconsistent with each other):
> >
> >     context D::cd(c : C, d : D):
> >     post A: result = Sequence { c, d }.collect( v | v.b }
> >     post B: result = Sequence { c, d }.collect( v | v.a }
> >     post C: result = Sequence { c, d }.collect( v | v.a + v.b )
> >
> > Questions:
> >
> > 1. What is the type of the subexpression Sequence { c, d }? The most 
> specific
> > common supertype of C and D is OclAny, so is it Sequence(OclAny)?
> > 2. Are postconditions A and B well-typed and well-defined? If the answer to
> > question #1 is Sequence(OclAny) then the answer is "no" and "no," right?
> > 3. Is postcondition C well-typed and well-defined? I am going to say 
> "no" and
> > "no" because there seems to be no way to type the iteration variable.
> > 4. I assume it is the case that expressions that are not well-typed are
> > undefined; i.e. an OCL expression evaluator is not required to accept any
> > expression that it cannot statically typecheck before attempting any
> > evaluation.
> > Is that correct?
> >
> > Thank you,
> > Brian
>
>
>__________________________________
>Do you Yahoo!?
>New Yahoo! Photos - easier uploading and sharing.
>http://photos.yahoo.com/
>
>
>
>To remove yourself from this list please mail puml-list-request@cs.york.ac.uk
>with a message containing the word "unsubscribe".

Date view Thread view Subject view Author view Attachment view