Stephan Szabo wrote:
> And whatever is done should leave arrays with the same meaning they
> currently have for people who use them in other ways. I'm almost
> thinking that we want a set rather than an array here where sets have
> different semantics that make more sense for this sort of behavior.
> It just seems to make more sense to me that a set would be indexed
> by its elements than array, since position is supposed to be meaningful
> for arrays, and that set(1,2) is equal to the set(2,1) whereas the
> indexes aren't. Of course, I guess that's not much different from
> the normalized table case.
Probably a collection rather than a set. No sense in excluding
duplicates.
What often happens in an ODBMS is that some general purpose collection
classes are written based on arrays. A simple example would be...
class Set<type> { RefArray<type> array;
}
Where RefArray<Object> gets mapped to something like oid[] in the odbms.
Then when you want a class that has a set..
class Person { Set<Car> owns;
}
which gets flattened and mapped to
create table Person (owns oid[]);
The set semantics being enforced by the language bindings.
