Re: MV Keys

Jon Heggland wrote:
> 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?

Well, what language support does String have? It has the overloaded + operator, and the string literal as shortcut constructor. So it's a little bit in the language. But most of its functionality is exposed through methods on java.lang.String. So it's mostly in the library.

Admittedly, String (and a few other classes) have one foot in both worlds in Java, as it were.

> > > 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.

Ah, yes. My feeling is also that if "compound" has any formal meeaning, then strings are compound, not scalar.

> > 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. :-)

> 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.)

> (Except that "list relations" can easily have more than one "data
> column"; lists typically can't---unless you use tuple types or something
> similar.

True.

> 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?)

At a high level, the principle is Data Independence; the semantics of the program should not depend on the implementation. (Although the performance of the program necessarily will.)

> 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.

Fair enough.

Marshall Received on Fri Mar 03 2006 - 19:34:31 CET