Re: MV Keys

Jon Heggland wrote:
> In article <1141410870.990244.203240_at_j33g2000cwa.googlegroups.com>,
> marshall.spight_at_gmail.com says...
> > > > 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?"
> >
> > Well, yes; that's actually what I'm trying to do. (And my answer to
> > "which ones?" design question is: relations and lists. :-)
>
> Oh, I thought you meant sets as opposed to relations.
>
> > > 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.
> >
> > Such is the nature of libraries.
> >
> > (But such would not be true for collections that were in the language.)
>
> Huh? The algorithm has to exist somewhere. Is the issue just how easy it
> is for the user of the library/language to see it?

Agree that the algorithm has to exist somewhere. But the form it can take as a library function is limited and probably monomorphic; as part of the language, it could be a parameterized code generator; it might not look anything like a Java method or a stored procedure.

> What advantage do Java arrays get from being "in the language" as
> opposed to the Collections API "in the library"? I know that the
> collections may not be present in special Java subsets (Micro Edition
> and such), but is that all? Is it the special syntax that is important?

Syntaxt can be important, but the issue I'm concerned about is semantics. In particular, I've seen lots of subtle difficulties caused by the fact that types systems generally don't distinguish between ordered and unordered data.

Marshall Received on Mon Mar 06 2006 - 16:54:37 CET