Re: MV Keys

In article <1141399209.093211.14150_at_z34g2000cwc.googlegroups.com>, marshall.spight_at_gmail.com says...
> Jon Heggland wrote:
> > And is the library/language distinction really that clear cut?
> > Is the String class in the language or in the library?
>
> Both. But the issue I'm trying to raise here is interface.
> And by those terms, we would say String is in the library.

Why? How do you make that decision?

> > and that the classification of types into compound and simple is
> > essentially arbitrary.
>
> Did I say that? I kind of believe that, but I kind of don't.

You said something along the lines of strings not being considered compound merely by convention, tradition and convenience.

> > What, then, is the use of talking about 1NF and
> > simple vs compound types at all?
>
> I think the choice of collections has a big impact on the
> utility of a language.

Without a doubt. But what is the use of talking about 1NF and simple vs compound types in that regard? Can't we just say "We want collection types. But which ones?"

> The relational operators don't handle lists very well.
>
> myList.removeAt(3)
>
> vs.
>
> BEGIN
> delete from MyList where Index = 3;
> update MyList set Index = Index - 1 where Index > 3;
> COMMIT
Yes. Though if you look at the implementation of removeAt(), you will probably find something rather similar to the SQL code there. Likewise, if you wrap the SQL code in a procedure, there is no real difference.

(Except that "list relations" can easily have more than one "data column"; lists typically can't---unless you use tuple types or something similar. The physical model might be a consideration, too. If you do a lot of indexOf() operations, it might be sensible to store the collection sorted on the data instead of on the index, as lists typically are. Or are you planning such features for lists in your system?)

Note that I'm not opposed to list or set attributes. I do think, however, that RVAs should be supported; everything else is just gravy.

-- 
Jon