From: Thomas D. <th...@de...> - 2007-07-19 08:55:00
|
Hi, I have two ET_CLASS objects: a and b. Assume that the first object (A) has one generic parameter. If that parameter is constrainted, I want to check if another object (B) conforms to the generic constraint. Based on my current knowledge, I guess I should use the conforms_to_type feature of ET_CLASS, but I don't know how to use this feature correctly in this case. The signature of conforms_to_type is: conforms_to_type (other: ET_TYPE; other_context: ET_TYPE_CONTEXT; a_context: ET_TYPE_CONTEXT; a_universe: ET_UNIVERSE): BOOLEAN So, I guess I should call this feature on object a. The question is then: what values do I have to fill in for the other arguments, except for a_universe? It think the value of other should be a.formal_parameters.item(1).constraint, so that leaves other_context and a_context to be filled in ... Thanks a lot in advance Kind Regards -- Thomas |
From: Eric B. <er...@go...> - 2007-07-19 10:27:21
|
Thomas Delaet wrote: > Hi, > > I have two ET_CLASS objects: a and b. > Assume that the first object (A) has one generic parameter. If that > parameter is constrainted, I want to check if another object (B) > conforms to the generic constraint. > > Based on my current knowledge, I guess I should use the > conforms_to_type feature of ET_CLASS, but I don't know how to use this > feature correctly in this case. > > The signature of conforms_to_type is: > > conforms_to_type (other: ET_TYPE; other_context: ET_TYPE_CONTEXT; > a_context: ET_TYPE_CONTEXT; a_universe: ET_UNIVERSE): BOOLEAN > > So, I guess I should call this feature on object a. You meant object b, not a. > The question is > then: what values do I have to fill in for the other arguments, except > for a_universe? > > It think the value of other should be > a.formal_parameters.item(1).constraint, so that leaves other_context > and a_context to be filled in ... The context is where your type comes from. For example the type 'like Current' has different meanings depending on whether it appears in class STRING or in class ARRAY. If the context is class STRING, then we can say that 'like Current' conforms to COMPARABLE, which is not the case if the context was ARRAY. Furthermore, in the context of 'LINKED_LIST [STRING]' type G conforms to STRING. So if your types appears in class C, for example: class A [G -> LIST [H], H] ... class B inherit LINKED_LIST [STRING] ... class C feature a: A [B, COMPARABLE] what we need to prove is that in the context of C the type B conforms LIST [H] in the context of A [B, COMPARABLE]. Which is indeed the case because B in the context of C is B itself, and 'LIST [H]' in the context of A [B, COMPARABLE] is nothing else but LIST [COMPARABLE], and B conforms to LIST [COMPARABLE]. As an example, have a look at ET_TYPE_CHECKER.check_class_type_validity. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
From: Thomas D. <th...@de...> - 2007-07-19 13:13:34
|
Thanks a lot! (again). Kind Regards Thomas On 7/19/07, Eric Bezault <er...@go...> wrote: > Thomas Delaet wrote: > > Hi, > > > > I have two ET_CLASS objects: a and b. > > Assume that the first object (A) has one generic parameter. If that > > parameter is constrainted, I want to check if another object (B) > > conforms to the generic constraint. > > > > Based on my current knowledge, I guess I should use the > > conforms_to_type feature of ET_CLASS, but I don't know how to use this > > feature correctly in this case. > > > > The signature of conforms_to_type is: > > > > conforms_to_type (other: ET_TYPE; other_context: ET_TYPE_CONTEXT; > > a_context: ET_TYPE_CONTEXT; a_universe: ET_UNIVERSE): BOOLEAN > > > > So, I guess I should call this feature on object a. > > You meant object b, not a. > > > The question is > > then: what values do I have to fill in for the other arguments, except > > for a_universe? > > > > It think the value of other should be > > a.formal_parameters.item(1).constraint, so that leaves other_context > > and a_context to be filled in ... > > The context is where your type comes from. For example the type > 'like Current' has different meanings depending on whether it > appears in class STRING or in class ARRAY. If the context is > class STRING, then we can say that 'like Current' conforms to > COMPARABLE, which is not the case if the context was ARRAY. > Furthermore, in the context of 'LINKED_LIST [STRING]' type G > conforms to STRING. > > So if your types appears in class C, for example: > > class A [G -> LIST [H], H] ... > class B inherit LINKED_LIST [STRING] ... > > class C > feature > a: A [B, COMPARABLE] > > what we need to prove is that in the context of C > the type B conforms LIST [H] in the context of > A [B, COMPARABLE]. Which is indeed the case because > B in the context of C is B itself, and 'LIST [H]' > in the context of A [B, COMPARABLE] is nothing else > but LIST [COMPARABLE], and B conforms to LIST [COMPARABLE]. > > As an example, have a look at ET_TYPE_CHECKER.check_class_type_validity. > > -- > Eric Bezault > mailto:er...@go... > http://www.gobosoft.com > -- Thomas |