Inconsistent returned value type of AsObject property.

[Roy Winata]

AsObject property of an IObjectList will return an Object,
but internally it can be an array of Object or an ObjectListAdapter.

When the ocl evaluated to create the IObjectList does not have a context
(e.g. ...Evaluate("Book.allInstances")) internally it will be array of
Object,
but when the the IObjectList has a context
(e.g. ...Evaluate(book, "self.Authors")) internally it will be
ObjectListAdapter.

Does any body know why the returned value of AsObject property of an
IObjectList is inconsistent?

[Anders Ivner]

I would recommend using the returned object as an IEnumerable or ICollection
only. I.e. don't call anything that modifies the list, such as Add() or
Remove().

As for why, I don't think there's a good reason.

/Anders

"Roy Winata" <r...@ptgdi.com> wrote in message
news:42fc...@newsgroups.borland.com...

[Roy Winata]

Anders,
If I call the Delete method of one of the IObject in IObjectList returned
from ...Evaluate("Book.allInstances->select(Price < 15)").
The deleted IObject will still be in the IObjectList (IObjectList.Count will
be the same before and after Delete()).
What is the proper way to handle this IObjectList (this will not happen if
the OCL does not contain ->select(..) expression, i.e. the IObjectList.Count
will be less after Delete()).

Regards,
Roy

"Anders Ivner" <anders...@borland.com> wrote in message
news:42fc64f4$1...@newsgroups.borland.com...

[Jan Nordén [Borland]]

Roy Winata wrote:

We didnt realy expect users to use AsObject on collections, rather to
iterate over the collection on the ECO side, and use AsObject on the
Elements.

So idea was really just to return an ICollection where the elemnts are
of the right type.

There was actually minor a point originally, in that AsObject for e.g.
Book.Authos will return something as similar as possible to the actual
property on the .Net side, and ObjectListAdapter is the superclass to
the typed adapters (e.g. BookListAdapter), so you can perform the same
operations, i.e. setting values etc. Also, returning the adapter is
cheap (in runtime), while creating an array is not.

The safest course is to ignore the actual type returned, and always
treat it as an ICollection.

--
Jan Nordén
Senior Software Architect
MDA products group

[Jan Nordén [Borland]]

Roy Winata wrote:

> Anders,
> If I call the Delete method of one of the IObject in IObjectList
> returned from ...Evaluate("Book.allInstances->select(Price < 15)").
> The deleted IObject will still be in the IObjectList
> (IObjectList.Count will be the same before and after Delete()).
> What is the proper way to handle this IObjectList (this will not
> happen if the OCL does not contain ->select(..) expression, i.e. the
> IObjectList.Count will be less after Delete()).

> >

There is actually a bit to explain here.

The IElement returned by an OCL evaluation will be either a reference
or a value. It will be a reference if it refers to something that
actually has a direct representation in the EcoSpace, i.e. either a
structural feature of an object (an Attribute or AssociationEnd) or an
extent (i.e. allInstaces of a class).

In all other cases it will be a value.

A reference will be live, in that it changes when the value in the
EcoSpace does, and can be modified, unless the IElement is ReadOnly, as
it will be for derived features, the extents, and the extra
association-ends added when there are link objects.

A value by contrast, will be a snapshot of the state when the
evaluation is performed.

If you want to sure to have a "snapshot" rather than a live value you
can do:

IElement possiblyLiveElement = oclService.Evaluate(...);
IElement stableElement = possiblyLiveElement.Clone(true);

If you want to be sure to have a "live" list, in your case one that
will change not only if a book is deleted, but also if the price of a
book changes or a book is added, then you can do:

IElement assuredlyLiveElement = oclService.GetDerivedElement(,,,):

Finally, if you want a snapshot of the position when the list was
evaluated, but with deleted objects still removed you can do:

IObjectList List = oclService.Evaluate(...).CloneValue(true) as
IObjectList;
List.RemoveDeletedObjects = true;

<Extra info>

This may also be a good time to point out the meaning of the parameter
to CloneValue() and the difference between IElement.ReadOnly and
IElement.Mutable.

The parameter determines if the new IElement (i.e. the clone) will be
ReadOnly or not.

If the parameter is true, then IElement.ReadOnly on the clone will be
true, and the clone can not be modified by the programmer

If the parameter is false, then IElement.ReadOnly on the clone will be
false, and you can modify it (e.g. add or remove objects from a list).
Such modifications will not affect the contents of the EcoSpace in any
way, it will just be a variable.

Mutable however tells if the list can change at all. A list may be
Mutable even if it is ReadOnly, in particular setting
RemoveDeletedObjects will make IElement.Mutable on the list true, since
it may change, even though it is readonly, i.e. may not be modified by
the programmer.

</Extra info>

[Peter Morris [Droopy eyes software]]

Hi Jan

This is very useful information. I think it is time to update your blog!

--
Pete
====
ECO Modeler, Audio compression components, DIB graphics controls,
FastStrings
http://www.droopyeyes.com

Read or write articles on just about anything
http://www.HowToDoThings.com

My blog
http://blogs.slcdug.org/petermorris/

[Roy Winata]

Thanks Jan,
Your explanation is very clear and thorough.

Thanks,
Roy