[wg11] Is an empty extensible select a specialization of anothertype?

[David Price]

My two cents are that this EXPRESS is invalid if that's all in the schema
under consideration. My understanding is that the SELECT being extensible
generic entity means any entity type can be added. So, it seems to me it is
not a specialization of Item_shape but is in fact a generalization of
Item_shape - and every other entity type in the schema.

However, if the SELECT was completed to contain only Item_shape subtypes,
then it would be legal - that's clear. It looks to me like if you just added
Item_shape to the select list you'd be legal per P11 right now. You could
write a rule to eliminate a direct instance of Item_shape from valid
instantiations in the modules that use this one if that's the intent.

Part 11 does not seem clear on whether the "select of a,b,c is
specialization of a if b and c are subtypes" is true for extensible select
types or not.

It does look like a useful construct in the modular architecture though.
Hope it's easy to enable in P11.

Cheers,
David

> -----Original Message-----
> From: wg11-bounces at steptools.com 
> [mailto:wg11-bounces at steptools.com] On Behalf Of Lothar Klein
> Sent: 13 May 2006 16:47
> To: wg11 at steptools.com
> Subject: [wg11] Is an empty extensible select a 
> specialization of anothertype?
> 
> 
> Please find below a discussion on the AP210 bugzilla system to the
> question whether or not an empty extensible select is a specialisation
> of another type in EXPRESS?
> 
> Do you think we have to do something on this?
> 
> -- 
> // Lothar Klein, LKSoftWare GmbH
> // Steinweg 1, 36093 Kuenzell, Germany
> // +49 661 933933-0, Fax: -2
> // url: http://www.lksoft.com
> 
> 
> Opened: 2006-04-29 17:31 by Lothar Klein
> 
> While looking to bug #2038 I detected another severe Express 
> issue which is
> clearly wrong, even if the Express compiler don't catch it 
> yet. Currently we have:
> 
>   ENTITY Shape_element; ...
>       containing_shape : Item_shape; ...
> 
>   ENTITY Non_feature_shape_element
>     SUBTYPE OF (Shape_element); ...
>       SELF\Shape_element.containing_shape RENAMED scope :
> ee_product_definition_with_annotation_elements; ...
> 
>   TYPE ee_product_definition_with_annotation_elements = EXTENSIBLE
> GENERIC_ENTITY SELECT ;
>   END_TYPE; -- ee_product_definition_with_annotation_elements
> 
> ee_product_definition_with_annotation_elements is not a 
> specialization of
> Item_shape and so this express is not valid. But fortunately 
> all the elements in
> the extensions are Item_shape.
> 
> Proposal is to simply remove the redeclaration of 
> containing_shape in the
> Non_feature_shape_element and remove the select with its extensions.
> 
> 
> ------- Additional Comment #1 From Tom Thurman 2006-04-30 
> 15:10 -------
> 
> Actually this is not a problem in EXPRESS.  As long as the 
> items are subtypes 
> of Item_shape the EXPRESS is legal.
> 
> 
> ------- Additional Comment #2 From Lothar Klein 2006-04-30 
> 17:59 -------
> 
> Sorry, but this is really a bug and I have to re-open it. We 
> may not be able to
> solve this for ed2.
> 
> The items are only added at a later time. Within schema
> Non_feature_shape_element_arm the extenable select
> ee_product_definition_with_annotation_elements can't be 
> considered as a
> specialization of Item_shape. At least I can't see which 
> statement in part11,
> e.g. "9.2.7 Specialization" would allow this. If you see then 
> please provide here.
> 
> 
> ------- Additional Comment #3 From Tom Thurman 2006-05-01 
> 12:32 -------
> 
> re-assign to Lothar to write SEDS against part 11 for clarification.
> -----------------------
> here is the definition of a SELECT type:
> 8.4.2 Select data type
> A select data type defines a data type that enables a choice 
> among several 
> named data types.
> The select data type is a generalization of these named data 
> types in its 
> domain. The defined
> type for which the select data type is the underlying 
> representation, may add 
> constraints on
> its domain by declaring local rules. A select data type may 
> be extensible or 
> not.
> -------------
> here is the applicable clause from 9.2.7:
> a select of a, b, c is a specialization of a select of d, e, 
> f if a, b, c are 
> specializations of
> d, e, f;
> ? a select of a, b, c is a specialization of a supertype if 
> a, b, c are 
> subtypes of the supertype;
> ------------------
> The interpretation of this by the compiler writers is that 
> the bullet from 
> 9.2.6 that specifies the behavior of select applies.
> I have seen this behavior where the compiler will allow the 
> use of EXTENSIBLE 
> SELECT as long as the leaf elements are subtypes of the original type 
> referenced by the attribute.
> I would suggest you write a SEDS against part 11, clause 9.2.7 to get 
> clarification or maybe a note to the wg11 exploder.
> --------------------------
> Another way of looking at this is the "expectation" that the 
> modules are all 
> compiled into a long form and this is something that will be 
> resolved there.
> ------------------------------
> 
> _______________________________________________
> wg11 mailing list
> wg11 at steptools.com
> http://lists.steptools.com/mailman/listinfo/wg11
>