SEDS for ISO 10303-11
Jochen Haenisch
Jochen.Haenisch at epmtech.jotne.com
Thu Nov 29 11:33:53 EST 2001
Hmmm ... I think I go into your text below.
> -----Original Message-----
> From: David Price [SMTP:david.price at eurostep.com]
> Sent: 29. november 2001 16:59
> To: Jochen Haenisch
> Cc: 'WG11 exploder'; Hans Karsten Dahl
> Subject: RE: SEDS for ISO 10303-11
>
> 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?
JH: maybe ... ?!?
> 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?
JH: Well, x is declared as a BAG; the value that is assigned to x is
a SET. So, the BAG behaves as a SET after the assignment. We seem to agree
on the problem statement, yes.
> If this is the case, then logically shouldn't TYPEOF only return SET,
> not BAG and SET, as the type of the x value?
YES - this seems to be the functionality that the user is interested
in!! Agreed.
In some cases one also needs the ISKINDOF-functionality. The two
usages, however, need to be distinguishable. Two keywords may be better than
one!
> 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.
JH: Yes, an instanceof or we call it: IS function. It sounds like a
good idea to distinguish this issue from the assignment issue. Concerning
this latter one: is this so disputable? The LRM says in 13.3, Assignment
statement:
"If the expression to the right of the assignment statement is an
entity instance, then the assignment
statement assigns a reference to that entity instance to the local
variable or parameter. After such an assignment, changes to the local
variable or parameter are rejected in the original instance. An assignment
statement may also be used to copy values to a local variable or instance,
when they are declared to be non-entity data types."
Well, yes, entity instances seem to be OK, but things like NUMBER
and aggregates are maybe not. Right?
Regards, Jochen.
> 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