Re: Date's First Great Blunder

"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:c5k8mo$umd$1_at_news.netins.net...
> "Eric Kaun" <ekaun_at_yahoo.com> wrote in message
> news:xZgfc.268$Ha4.262_at_newssvr16.news.prodigy.com...
> > "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
> > news:c5jopp$hdq$1_at_news.netins.net...
> > > There is not
> > > one correct mathematical model for data, metadata, nor functions (by
> > > whatever names).
> >
> > "Correct"? Is that even possible?
>
> Nope, unless you think it is possible to have a correct metaphor.

Nope, not me.

> > > > Many people confuse a class with its definition.
> > >
> > > Me, for exampe. The term is used both ways. I prefer to think of a
> class
> > > as a specification for (that is, metadata regarding) a domain/type.
> What
> > we
> > > can "see" of the class is a specification "in writing" (e.g.
> MyType.java)
> > > and a compiled version of that spec (e.g. MyType.class). The set of
> > objects
> > > that could be instantiated by way of this specification of the type is
> > more
> > > abstract. So, I prefer using the term "class" as a definition/spec of
a
> > > type and the term "type" as the more abstract (invisible) set. I
think
> > this
> > > helps avoid some of the confusion in terms, perhaps, maybe, a little
> bit.
> >
> > So a class is simply an implementation of a type? That seems to be what
> > you're getting at.
>
> "Type" is not my favorite word, but if, indeed, it is the very same word
as
> "domain" then it seems to me that a class is the specification of a
domain.

I think Alfredo suggested that domain was type without the operators. Could well be the case, but I'll just stick with type and only mention the operators when they're important.

I'd say a class CAN BE an implementation of a domain. But classes must also be other things, because not every bit of functionality and data in a system is a domain. Specifically, relations, which speak of values (of their attribute types), but are not in and of themselves types. (strong caveat here - it strikes me that I don't have the precise language to differentiate attribute types from relation heading types, since Date does agree, of course, that relations have types. I'll have to think about this more. Tuples are values of a type, and so are relations, so there are TUPLE and RELATION type generators, and they have operators as well - the operators on relations are the algebra. Or am I oversimplifying? Sorry, just mumbling to myself...)

> The class itself is not the domain "set" but, rather, an object of
software
> that specifies the domain. I suppose that one could equate a
specification
> with a set and surely there is a mapping (a function) from the spec to the
> domain.

Yes, although most developers use them strictly as variables, and abuse them horribly. I like the line that relational theory draws between types and relations.

> What gives "declarative" a description of metadata that OO or functional
or
> procedural or whatever other languages would not be able to claim? --dawn

With OO and procedural, the metadata must be separately maintained or laboriously derived from the code - not an easy process. Functional is a different matter I lack the expertise to discuss much, but it's also declarative in that lazy vs. strict implementations can decide on the order of evaluation of expressions (unlike procedural). With "declarative" (correctly placed in quotes), what you declare is the "metadata" (although we're not really talking about data here). It's just executable (e.g. a higher level of abstraction).

Keep in mind that OO is simply procedural with some packaging (although I don't know about the inclusion of objects in Lisp and other non-procedural languages).

And, as a final caveat, you can induce "proceduralism" to some degree in many functional and logic languages. They just don't mandate it, and make it awkward.

Anyone proficient in those languages, feel free to correct me...

• erk