Bob,

Thanks for the further feedback.

>In the actual use case that led to my discovery of this bug, I'm really not sure what the author’s intent was. I could go in to the specifics of the code but I'm not really sure if it is beneficial to do so. It ended up being a class that is low in cohesion, so I really don’t have a specific use case.

I understand how that goes.

>However, if one were to have an object that allowed something else using it to assign any of its members anything they wanted to, I’d think it would be a good idea to do some type checking before an assignment was made. I mean isn’t that what the _assign method is for, guarantee a precondition is met before an assignment was made? If so then I’d say Object members are no exception, why not check to see if an object that is trying to be assigned to a member is a specific user defined data type? This would guarantee that the object that has exposed object members will only allow assignments of objects that are a specific type. I don’t know this seems to make sense to me.

Yes, if you type check it and it's not object then not doing the assign should not cause latent C05s.

If it is an object and you check to make sure it supports the correct interface that the rest of the class code is expecting it to have that provides the conditional assignment requirement. Hopefully this bug will get cleaned up so that workaround code could be removed.

I use containership for this sort of object aggregation more so than using association via an object reference. Some times it's handy to be able to do all the composition at design time by dropping the desired items in, others it's easier to AddObject() the components. I use a function IsDerivedFrom() that tells me if a particular object is derived from the class that provides the expected interface. IsDerivedFrom() is also used when iterating through the objects[] collection to determine which objects should have the call passed on to. For example:

local loObject

* create all the import cursors

for each loObject in this.Objects
   if ( IsDerivedFrom( loObject, "cParseFile" ) )
      loObject.CreateCursor()
   endif
endfor

but this sorta digresses.

There are definate places where association is better than aggregation, and others where aggregation is better than association. Access/Assign give us control over the association technique and we have the overrideable AddObject() to control the runtime aggregation and can use Init() to verify that the designtime aggregation was valid.