[wg11] EXPRESS (DERIVEd) attribute redeclaration question

[Phil Spiby]

Tom,

I agree with you that where possible you should use the pattern of redeclaring the nearest attribute declaration so as to avoid confusion.
However, we cannot mandate this since we could have a diamond structure as identified by Lothar:

TYPE positive = INTEGER;
WHERE SELF > 0;
END_TYPE;

TYPE odd_integer = INTEGER;
WHERE ODD(SELF);
END_TYPE;

ENTITY a;
 x: INTEGER;
END_ENTITY;

ENTITY b
 SUBTYPE OF (a);
 SELF\a.x : positive;
END_ENTITY;

ENTITY c
 SUBTYPE OF (a);
 SELF\a.x : odd_integer;
END_ENTITY;

ENTITY d
 SUBTYPE OF (b, c);
DERIVE
 SELF\b.x : positive := 5;
 SELF\c.x : odd_integer := 5; -- or this
 SELF\a.x : INTEGER :=5; -- or even this
END_ENTITY;

We have to be able to cope with all these situations in EXPRESS.
The guidance, if provided should be given in SC4 recommended practices not in the EXPRESS manual.

Phil

-----Original Message-----
From: thomas thurman [mailto:thomas.r.thurman at imonmail.com] 
Sent: 07 June 2012 17:40
To: Phil Spiby
Cc: thomas thurman; Jochen Haenisch; Lothar Klein; wg11
Subject: Re: [wg11] EXPRESS (DERIVEd) attribute redeclaration question

Phil,
The EXPRESS training provided decades ago to AP developers provided a pattern to use going down a SUBTYPE tree.
That pattern of course was:

TYPE positive_integer = INTEGER;
WHERE
 WR1 : I am greater than zero;
END_TYPE;

ENTITY a;
 foo: OPTIONAL string
 bee : NUMBER;
END_ENTITY;

ENTITY b
 SUBTYPE OF (a);
 SELF\a.bee : INTEGER;
END_ENTITY;

ENTITY c
 SUBTYPE OF (b);
 SELF\b.bee : positive_integer;
END_ENTITY;
=======================recent pattern========== Recently I am seeing this pattern:
TYPE positive_integer = INTEGER;
WHERE
 WR1 : I am greater than zero;
END_TYPE;

ENTITY a;
 foo: OPTIONAL string
 bee : NUMBER;
END_ENTITY;

ENTITY b
 SUBTYPE OF (a);
 SELF\a.bee : INTEGER;
END_ENTITY;

ENTITY c
 SUBTYPE OF (b);
 SELF\a.bee : positive_integer;
END_ENTITY;
====================================================

This is why I requested a note because when I read the relevant section in the LRM, I see examples of the form Lothar mentioned earlier in this thread and that form is not related to my request.
[I find the "recent pattern" to be more expensive to maintain than the historical pattern since the "recent pattern" hides the intermediate redeclarations. E.g., If these ENTITY declarations are in interfacing schemas and someone modified the ENTITY "b" to redeclare "bee" as a REAL.]

Tom

>On Jun 7, 2012, at 2:48 AM, Phil Spiby wrote:

> Looking at the files in more detail I agree with Jochen.
> The redeclaration at line 24446 is not a specialization of either the original declaration or any of the lower redeclarations so is in error irrespective of where things are declared.
> 
> My first answer was basically in response to the position by Tom that there should be a note in the EXPRESS LRM that there should be information in the LRM concerning redeclaration order and consequences - which I believe is covered by the rule I pointed out. 
> 
> Phil
> 
> -----Original Message-----
> From: thomas thurman [mailto:thomas.r.thurman at imonmail.com]
> Sent: 07 June 2012 02:04
> To: Jochen Haenisch
> Cc: thomas thurman; Lothar Klein; Phil Spiby; wg11
> Subject: Re: [wg11] EXPRESS (DERIVEd) attribute redeclaration question
> 
> Thanks Jochen!
> 
> Best Regards,
> Tom
>> On Jun 5, 2012, at 5:26 AM, Jochen Haenisch wrote:
> 
>> Tom,
>> 
>> my conclusion is that the error message is correct. According to P11
>> 9.2.7 Specialization, only the data type counts when determining 
>> whether a redeclared attribute follows the specialization rule or not.
>> Assignments have in this context nothing to say.
>> 
>> Best regards,
>> Jochen
>> -----Original Message-----
>> From: wg11-bounces at steptools.com [mailto:wg11-bounces at steptools.com]
>> On Behalf Of Thomas Thurman
>> Sent: 1. juni 2012 23:34
>> To: Lothar Klein
>> Cc: wg11
>> Subject: Re: [wg11] EXPRESS (DERIVEd) attribute redeclaration 
>> question
>> 
>> 
>> On Jun 1, 2012, at 3:27 PM6/1/12, Lothar Klein wrote:
>> 
>>> It has been always this way.
>>> And the classical example is that if an entity A has an explicit 
>>> INTEGER attribute and two subtypes B and C. In B the attribute is 
>>> redeclared to be an odd number and in C to be an even number and 
>>> there is an entity D that is a subtype of both, B and C then all 
>>> this is valid Express. But it is not possible to construct a valid 
>>> instance of D because you won't find an integer value that is both 
>>> an odd and an
>> even
>>> number simultaneously.
>> Sorry, we seem to be getting off track.
>> I was specifically talking about the case where there are three 
>> declarations in a direct supertype path, The root supertype, an 
>> intermediate type and the leaf subtype.
>> Let's not mix up the problem statement.
>> 
>> Tom
>>> 
>>> Lothar
>>> 
>>> Friday, June 1, 2012, 3:42:25 PM, you wrote:
>>>> Phil,
>>>> This is an interesting conclusion. I look forward to hear opinions 
>>>> of
>> other members of WG11.
>>> 
>>>> Tom
>>>>> On Jun 1, 2012, at 12:43 AM6/1/12, Phil Spiby wrote:
>>> 
>>>>> I believe Rule and Restriction (e) under section 9.2.3.4 applies:
>>>>> e) If an attribute of a supertype is redeclared in two 
>>>>> non-mutually
>> exclusive subtypes, an
>>>>> instance which contains both subtypes shall have a single value 
>>>>> for
>> that attribute which is
>>>>> valid for both redeclarations.
>>>>> 
>>>>> Phil
>>> 
>> 
>> 
>> _______________________________________________
>> wg11 mailing list
>> wg11 at steptools.com
>> http://lists.steptools.com/mailman/listinfo/wg11
> 
> Notice: This e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged.  If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited.  Please reply to the sender that you have received the message in error, then delete it.  Thank you.
> 
> 

Notice: This e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged.  If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited.  Please reply to the sender that you have received the message in error, then delete it.  Thank you.