SEDS for ISO 10303-11
David Price
david.price at eurostep.com
Thu Nov 29 10:58:43 EST 2001
Jochen,
In my example, are you suggesting that an implementation not allow any
change to the value of x if the change would result in making a BAG of what
was originally a SET? In other words, through assignment you've forced that
one value of x, which is declared as a BAG, into behaving as if it was a
SET? If this is the case, then logically shouldn't TYPEOF only return SET,
not BAG and SET, as the type of the x value?
I was beginning to that that perhaps the SEDS was really asking for an
INSTANCEOF function, like the one you mentioned from SDAI. However, if
assignment limits further changes to a value then it goes beyond that.
Cheers, David
> -----Original Message-----
> From: Jochen Haenisch [mailto:Jochen.Haenisch at epmtech.jotne.com]
> Sent: 2001 November 29 15:32
> To: 'david.price at eurostep.com'
> Cc: 'WG11 exploder'; Hans Karsten Dahl
> Subject: RE: SEDS for ISO 10303-11
>
>
> David,
>
> no! Changing the population within the aggregate would not change the
> aggregate type. If the object that was assigned to the BAG parameter is a
> SET, it will remain a SET even if you try to make an invalid change to its
> elements.
> By the way, I think that at least the union operator does not allow us to
> add a duplicate element into a SET (which may be declared as a BAG, but be
> populated with a SET) and, thus, make the SET invalid.
>
> A good discussion - thank you and Ed, and Hans Karsten over here :-)
>
> Regards, Jochen.
>
> > -----Original Message-----
> > From: David Price [SMTP:david.price at eurostep.com]
> > Sent: 29. november 2001 15:07
> > To: Jochen Haenisch
> > Cc: 'WG11 exploder'; Hans Karsten Dahl
> > Subject: RE: SEDS for ISO 10303-11
> >
> > Jochen,
> >
> > Thanks, I think I understand the SEDS now. For any case where a variable
> > has
> > a declared type, assignments of a value of the variable to
> other variables
> > or attributes shall maintain the original type so that TYPEOF can return
> > the
> > original type too.
> >
> > A clarification question... given the BAG/SET example, if I add
> 2 as a new
> > member of the x that has been assigned the SET [1,2,3] would you expect
> > only
> > BAG to be returned by TYPEOF? I assume so. That means it's more
> than just
> > assignment that is affected. I think it means that the type of the
> > assigned
> > value must be maintained and then every operation that changes the value
> > must check if the change causes a change in any of its types.
> >
> > I imagine this adds complexity to implementations but as I said, I'll
> > leave
> > that issue to others.
> > Cheers,
> > David
> >
> > > -----Original Message-----
> > > From: Jochen Haenisch [mailto:Jochen.Haenisch at epmtech.jotne.com]
> > > Sent: 2001 November 29 13:48
> > > To: 'david.price at eurostep.com'
> > > Cc: 'WG11 exploder'; Hans Karsten Dahl
> > > Subject: RE: SEDS for ISO 10303-11
> > >
> > >
> > > David,
> > >
> > > if TYPEOF is supposed to work like is_kind_of already - great.
> > > Then we only
> > > need to polish the describing text in the LRM. This is indeed what I
> > hoped
> > > for!
> > >
> > > NUMBER is only a special case for which TYPEOF also should return
> > > the actual
> > > type of the parameter value (not only the declared one).
> > >
> > > Same for aggregates, but only if they are really assigned a different
> > type
> > > of aggregate:
> > > LOCAL
> > > x : BAG OF INTEGER;
> > > y: SET OF INTEGER := [1,2,3];
> > > END_LOCAL;
> > > x := y;
> > > In this case TYPEOF(x) should return ['SET', 'BAG'], not only ['BAG'].
> > >
> > > If you have:
> > > LOCAL
> > > y: BAG OF INTEGER := [1,2,3];
> > > END_LOCAL;
> > > TYPEOF(x) should only return ['BAG'].
> > >
> > > The assignment is the point! Only then the program can really
> > > trace the type
> > > of an instance.
> > >
> > > I hope that makes my issue clearer?!?
> > >
> > > Regards, Jochen
> > > > -----Original Message-----
> > > > From: David Price [SMTP:david.price at eurostep.com]
> > > > Sent: 29. november 2001 14:28
> > > > To: Jochen Haenisch
> > > > Cc: 'WG11 exploder'; Hans Karsten Dahl
> > > > Subject: RE: SEDS for ISO 10303-11
> > > >
> > > > Jochen,
> > > >
> > > > When you said it didn't apply to BAG and SET I assumed NUMBER
> > > was the only
> > > > case. The is_instance_of and is_kind_of only apply to entity
> > instances,
> > > > not
> > > > simple data types, in SDAI so it's not quite the same
> thing. Actually,
> > I
> > > > think TYPEOF already works as you want in the case of entity
> > > instances. It
> > > > seems you are asking for simple types, but not aggregation types, to
> > be
> > > > treated the same as entity instances because you believe all data
> > values
> > > > will be represented as objects and therefore can maintain the
> > > data type of
> > > > whatever was most recently assigned. Is that right?
> > > >
> > > > Sorry to be a pain but I seem to be confused as to the extent of the
> > > > request
> > > > in this SEDS.
> > > > Thanks,
> > > > David
> > > >
> > > > > -----Original Message-----
> > > > > From: Jochen Haenisch [mailto:Jochen.Haenisch at epmtech.jotne.com]
> > > > > Sent: 2001 November 29 13:05
> > > > > To: 'david.price at eurostep.com'
> > > > > Cc: 'WG11 exploder'; Hans Karsten Dahl
> > > > > Subject: RE: SEDS for ISO 10303-11
> > > > >
> > > > >
> > > > > Daivd,
> > > > >
> > > > > yes, I do mean that this applies to more than NUMBER! Think of an
> > > > example
> > > > > with PERSON and subtypes MAN and WOMAN. That would make
> more sense.
> > > > > If I am not mistaken, SDAI offers the required functionality in
> > > > > is_instance_of/is_kind_of.
> > > > >
> > > > > Regards, Jochen.
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: David Price [SMTP:david.price at eurostep.com]
> > > > > > Sent: 29. november 2001 13:57
> > > > > > To: Jochen Haenisch
> > > > > > Cc: 'WG11 exploder'; Hans Karsten Dahl
> > > > > > Subject: RE: SEDS for ISO 10303-11
> > > > > >
> > > > > > Hi Jochen,
> > > > > >
> > > > > > My two kroner...
> > > > > >
> > > > > > I do agree NUMBER is a strange datatype but I'm not sure that
> > means
> > > > the
> > > > > > relationship between it and a specialiation of it should be
> > treated
> > > > > > differently OR do you mean for this to apply to more
> than NUMBER?
> > > > > >
> > > > > > > An implementation will nontheless keep track of the
> actual type
> > of
> > > > an
> > > > > > > object. So, why not give the user the (necessary)
> possibility to
> > > > > > > query this?
> > > > > >
> > > > > > I'm not sure it's a good idea to assume this for all
> > > implementations.
> > > > > > Functionally, NUMBER is treated like REAL in many of the 20s
> > > > > series parts
> > > > > > so
> > > > > > implementations may lose the distinction. However, I've not
> > > > implemented
> > > > > > this
> > > > > > myself so will leave that issue to others.
> > > > > >
> > > > > > Cheers,
> > > > > > David
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Jochen Haenisch
> [mailto:Jochen.Haenisch at epmtech.jotne.com]
> > > > > > > Sent: 2001 November 29 12:24
> > > > > > > To: 'david.price at eurostep.com'
> > > > > > > Cc: 'WG11 exploder'; Hans Karsten Dahl
> > > > > > > Subject: RE: SEDS for ISO 10303-11
> > > > > > >
> > > > > > >
> > > > > > > David,
> > > > > > >
> > > > > > > no, the point is not to detect that a BAG is a SET
> based on the
> > > > > > > characteristics of its population. This is beyond the limits,
> > but
> > > > not
> > > > > > very
> > > > > > > much. The point is to have a possibility to query
> which type of
> > > > value
> > > > > > has
> > > > > > > intentionally been assigned to a parameter.
> > > > > > >
> > > > > > > Building on the previous example one could imagine
> the following
> > > > > > > situation:
> > > > > > >
> > > > > > > LOCAL
> > > > > > > x : NUMBER;
> > > > > > > y: REAL := 1.0;
> > > > > > > z: INTEGER := 2;
> > > > > > > END_LOCAL;
> > > > > > >
> > > > > > > IF (...) THEN x:=y;
> > > > > > > ELSE x:=z;
> > > > > > > END_IF;
> > > > > > >
> > > > > > > IF ('REAL' IN TYPEOF(x)) THEN ...; END_IF;
> > > > > > >
> > > > > > > Even though this may not be the most convincing real life
> > > example, I
> > > > > > hope
> > > > > > > you see the usefulness of TYPEOF returning the type
> of the value
> > > > that
> > > > > > has
> > > > > > > been assigned to it. How else could one treat x differently
> > > > > based on the
> > > > > > > type that it is carrying around?
> > > > > > > An implementation will nontheless keep track of the
> actual type
> > of
> > > > an
> > > > > > > object. So, why not give the user the (necessary)
> possibility to
> > > > > > > query this?
> > > > > > >
> > > > > > > Best regards, Jochen.
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: David Price [SMTP:david.price at eurostep.com]
> > > > > > > > Sent: 29. november 2001 12:13
> > > > > > > > To: Jochen Haenisch
> > > > > > > > Cc: 'WG11 exploder'
> > > > > > > > Subject: RE: SEDS for ISO 10303-11
> > > > > > > >
> > > > > > > > Jochen,
> > > > > > > >
> > > > > > > > I'm not sure I like the idea that the datatype of something
> > > > > > > depends on its
> > > > > > > > instantiated value. TYPEOF is a datatype, not data value,
> > > > > > > function so I'm
> > > > > > > > a
> > > > > > > > bit confused. Can you elaborate on why you want this change?
> > Is
> > > > this
> > > > > > > > example
> > > > > > > > any different from x being declared as a BAG that happens to
> > be
> > > > > > > > instantiated
> > > > > > > > with non-duplicate members and so you want TYPEOF to return
> > SET?
> > > > > > > >
> > > > > > > > Hope my question makes sense. It's basically, how far would
> > > > > you expect
> > > > > > > > this
> > > > > > > > proposal to go?
> > > > > > > >
> > > > > > > > Cheers,
> > > > > > > > David
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: owner-wg11 at steptools.com
> > > > [mailto:owner-wg11 at steptools.com]On
> > > > > > > > > Behalf Of Jochen Haenisch
> > > > > > > > > Sent: 2001 November 29 09:02
> > > > > > > > > To: 'seds at cme.nist.gov'
> > > > > > > > > Cc: 'WG11 exploder'
> > > > > > > > > Subject: SEDS for ISO 10303-11
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Please, consider the SEDS report that is included below.
> > > > > > > > > Best regards, Jochen Haenisch.
> > > > > > > > >
> > > > > > > > > <<SEDS_Express_20011129.txt>>
> > > > > > > > >
> > > > > > > > >
> ____________________________________________________________
> > > > > > > > > Jochen Haenisch E-mail:
> > > > > > > > > Jochen.Haenisch at epmtech.jotne.com
> > > > > > > > > EPM Technology AS Home of the EXPRESS Data
> > Manager
> > > > > > > > > P.O Box 6629 Etterstad Tel: Int +
> 47 23 17 17 26
> > > > > > > > > N-0607 Oslo Fax: Int +
> > > 47 23 17 17 01
> > > > > > > > > Norway Web:
> > > > > > > > > http://www.epmtech.jotne.com
> > > > > > > > >
> > > > > > > > >
More information about the wg11
mailing list