Re: Collection classes
Re: Collection classes
- Subject: Re: Collection classes
- From: "Timothy Reaves" <email@hidden>
- Date: Thu, 8 Jan 2004 09:08:50 -0500 (EST)
What's not to like? Are you kidding? :-)
New classes might not be needed, but some new functionality is. Whereas
I'm still learning Objective-C, I'm not sure what I want can be done with
an interface, although if it could, that'd be fine.
What is missing is the ability to order collections.
NSArray is an ordered, unbounded collection. So that can be used as a
list. That's fine. But having NSArray be the only ordered collection is
a bit limiting.
I need a set. A set excludes duplicates, and is not ordered. It is not by
definition unordered, it is just that order is not imposed. That is a
fine distinction, but a distenction none-the-less. Now, for what I am
currently working on, I also need order. I can find no ordered collection
with set symantics in the Cocoa class library.
I am implementing a table data source. I have a class (Foo) that has an
instance attribute (bar) of type NSMutableSet that I want to have the
table display. The contract of bar is that it not allow duplicates, so it
HAS to be a NSSet*, as that is the only collection that enforces that
contract. The Cocoa data sources in Cocoa want collections that are
indexable, and I understand why.
But how should I then model my non-indexable collection in an indexable
way? So far I have not found an easy way to do this in Cocoa. Converting
the collection to an NSArray doesn't work, because the then as additions
and deletions are made I must update two objects! Not good. What is
needed is an NSOrderedSet; whether that is accomplised as a class, or
simply adding a catagory doesn't really matter.
It is possible that the internal ordering of NSSet* does not change; for
all I know they internally hold there data in an NSArray* (or more
probably a dictionary). One could then assume that whereas the collection
is unordered, the order is not mutable. But that is not specified in the
contract of the class, and it would be breaking several design rules to
code to the assumption instead of the interfaces contract.
The symantics of lists and sets are needed, but so are the symantics of
ordered vs. unordered, and these are not mutually exclusive.
P.S.
In the shop I now work in, Java is the language of choice. There have
been several people complain that Java has too many collection classes to
chose from. In all cases, this was because they did not understand
collections, and did not understand interfaces. Java does not have too
many to chose from.
Whereas not everone will need to diferentaite between a Tree vs. Hash
implementations of a Set, there are times when one is more appropriate
that the other. But which one the programmer chooses to use shouldn't
matter, as the contract should be that a Collection or Set be used. I
have seen lots of code where a public interface specifies that a method
accept a HashSet as a parameter, and this is almost always wrong! The
actual need is for a Collection, or in some cases a more specific form
such as Set or List. But there is almost never any reason to have a
contract specify an actual concreate implementation class as the
parameter.
>
What language - Objective C?
>
>
What's not to like?
>
>
You get an ordered collection (NSArray), an associative one
>
(NSDictionary) and an unordered set (NSSet). Its pretty pointless to
>
use different collection classes - all of the interfaces in Cocoa
>
expect collections to be one of those or their mutable variants. If
>
you haul off and write one of your own or find something somewhere
>
(unlikely to be honest - the ones that exist are adquate for most
>
things) it will be relatively useless unless it implements enough of
>
the protocol of the existing classes to be a convincing replacement.
>
>
Which means that you might as well add categories of methods that you
>
do like to the existing classes so you can actually use them with other
>
classes in Cocoa.
>
>
Incidentally - this is one of the annoyances with Java - there are too
>
many friggin collection class interfaces and you're constantly
>
converting types for stupid reasons. Unless you have a really
>
compelling reason to do a custom collection, you're much better off
>
using what's there - maybe with some nifty add on methods.
>
>
On Jan 7, 2004, at 7:32 PM, T Reaves wrote:
>
>
> Are there any good collection class frameworks out there? I'm not too
>
> happy with the default ones.
>
>
>
> [demime 0.98b removed an attachment of type
>
> application/pkcs7-signature which had a name of smime.p7s]
>
> _______________________________________________
>
> cocoa-dev mailing list | email@hidden
>
> Help/Unsubscribe/Archives:
>
> http://www.lists.apple.com/mailman/listinfo/cocoa-dev
>
> Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.