Mailing Lists: Apple Mailing Lists

Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Questions about implementations of OSSet and OSArray



On Thursday, March 28, 2002, at 08:26 PM, Alfonso Guerra wrote:

From: Shawn Erickson
On Thursday, March 28, 2002, at 12:24 PM, Al Guerra wrote:

1. Why is OSArray a member of OSSet instead of its superclass? Is there
some advantage to this in the subset of C++ used?

Both OSArray and OSSet decend from OSCollection (not that OSCollection
does much). OSArray allows index based access to members and will grow
as needed. OSSet doesn't allow index based access, it is intended to act
as an unordered set of unique objects.

With that in mind it doesn't make much sense for it to inherit from
OSArray since it doesn't act like one. The fact that it currently uses
an OSArray internally as its data store is unrelated (for large sets
using an array doesn't make much sense either so keep that in mind when
using OSSet).

It does make sense. That is the point of inheritance: to reuse existing code and reduce space and time requirements with one's parent's methods rather than accessing data as a client.

That is one reason... others include refinement of functionality or for up casting for collection reasons, etc.

For example, OSSet's methods withCapacity() and initWithCapacity() before and after reclassifying it as a subclass of OSArray:

Yeah, it could reuse some code by making this change but my original point it now your set has array specific methods that it doesn't need. If some code exists in common between set and array then it would be better to move it up to OSCollection.

Also by moving OSSet under OSArray you are somewhat forcing an implementation onto it. OSSet could just as well be implemented using a hash or tree for more efficient searching.

Many ways to slice this...

Is it just me or does it appear to
add the array from the other set and not its members. I think it should
be calling merge(set->members) not setObject(set->members).

It sure looks that way to me. OSSet::merge(OSSet *) calls OSSet::setObject(OSMetaClassBase *) passing the OSArray set->members which would incorporate the array (but not the set which owns it, which will make for leaks when the set is freed.) It's a nice, indirect way to create a tree, though.

I guess I should submit a bug on this.

It does seem a little strange to me as well... as coded it will return
true if any but not all members were merged.

Correct. If it were able to successfully add a single element, but failed to grow to add any more it would still return true.

Maybe a bug on this aspect as well.

-Shawn
_______________________________________________
darwin-development mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-development
Do not post admin requests to the list. They will be ignored.

References: 
 >Re: Questions about implementations of OSSet and OSArray (From: "Alfonso Guerra" <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.