Re: Date's First Great Blunder

"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:c5k6rt$6gp$1_at_news.netins.net...
> OK. I'll yield to your expertise on that. I have examples in hand with
> such a pattern, and have done it myself (but am, admittedly a beginner
Java
> coder), but have not done it with an RDBMS.

There are variations on such a pattern, but all of them revolve around putting as little code into each class as possible, or better yet using tags and generating something, or using Reflection, etc. Even generating "persistable" subclasses from the "pure" classes.

Also, I wasn't trying to be disparaging to beginners.

> > At most, I'd generate such with XDoclet or another tool. Such techniques
> > scale very poorly, especially when you have object graphs - does only
the
> > parent get "persistence methods", or the children too? There are many
more
> > flaws with this, but suffice it to say that no OO programmer (other than
a
> > beginner) would handle "persistence" this way.
>
> I suspect, then, that is true if the data model is relational.

Definitely - although I've encountered similar ugly problems even with XML persistence which, even though XML corresponds much better to traditional objects than either does to relational, has ugly issues of its own.

> > That set also has a specification. And a type has operators too.
>
> So does it "work for you" to consider a class to be the very same thing as
a
> type?

Yes - I focus on types, making my classes immutable whenever possible. But then there's no real analog to relations, so one ends up with various other objects (that fit into various patterns) to fill that gap. But there are many ways to skin that cat, most poorly studied (everyone has a great suggestion on how to do it), and all suggest the absence of... well, you can fill in the blank.

And all of that is just for persistence - the value of constraints is another large gap. Most OO languages are pure implementation, which gives much room for programmers to blunder and violate any number of useful principles.

> > How does a type differ from its specification? See "set intension" vs
> > "set extension."
>
> OK -- I'm not familiar with those terms.

Roughly, intension is the set's formulaic definition while extension is the enumerated list of elements (e.g. "{x | x>1}" vs. "{2, 3, 4, ...}" ).

> > > Or in the same for as other data, agreed. Code is metadata..
> >
> > About what?
>
> The software "object" for which it is the specification.

So code is the specification for a software object? I take it because object is quoted that you mean more than OO-style objects?

I'm not just splitting hairs - I think these are genuine issues. I don't think code is metadata - I think it's implementation of a "spec". (Spec meaning, loosely, constraints such as preconditions, postconditions, invariants.) "Declarative code" is the spec - if you have a declarative language, no separate implementation is needed (and in any event, in Tutorial D and such the implementation is separate and outside the model).

> > What data does it concern?
>
> The data that is software.

Code can't be considered to be metadata about software-as-data, because typically the code is the software. And in any event, (procedural) code is difficult to reason about, which is why specs are useful.

> > Another flaw in OO is its (usual)
> > requirement that every bit of code be tied to one class, regardless of
how
> > many classes it concerns.
>
> Given the amount of reuse in OO, I don't understand this angle. Can you
> give an example of this flaw?

As an aside, check out some "functional" languages (Haskell, ML, Lisp) for a look at effective reuse without objects. Reuse is hard for human reasons, and OO doesn't really help much. Inheritance, the unique OO spin on reuse, is overrated and, done poorly, undermines other useful properties like substitutability and interface definitions.

But regarding my statement, it's impossible in many OO languages to define a function without a preferred parameter. I can't do "doFoo(x, y)", but instead have to do either "x.doFoo(y)" or "y.doFoo(x)". In my experience, small adjustments in requirements (i.e. normal app evolution) can really play havoc with your code, because you've had to allocate each and every bit of functionality to a single class - when things change, the definition of which class is "primary" can easily change. Then you have to move the method (if you want to stay sane). Then the cascade starts.

If your class is a type (domain), then you're less likely to have this problem, since its methods will refer to it and it alone. It's the interfaces between classes that cause the problem, or rather the need to choose Class A or Class B as the "home" for every function. In the assignment "x = 1.2 + 3", should the + operator be assigned to the RATIONAL class (for the 1.2 literal) or the INTEGER class (for the 3 literal)?

I do appreciate a namespace structuring (a la Java packages). But the "everything is an object" philosophy (and its variant "everything belongs to one object class") is very limiting. It certainly hampers the refactoring that is the darling of agile methodologies (the darling of OO developers), resulting in a lot more work.

• erk