Re: Date's First Great Blunder

"Eric Kaun" <ekaun_at_yahoo.com> wrote in message news:4Lhfc.281$%r4.200_at_newssvr16.news.prodigy.com...
> "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.

There is a certain point where in order to give software developers the tools they need to do their jobs well, we have to give them enough rope to hang themselves.

> > > 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, ...}" ).

OK, then I see a class as the intension and the domain as the extension.

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

Yes, I didn't want it to be centered on OO stuff,

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

If someone uses an IDE and the specification of a GUI component, such as a drop-down, is stored in the IDE, do you consider such stored information to be metadata related to the developed software? It is data about the "data" (the latter data being software components). Similarly, the written code is a specification of the software that runs.

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

"The code is the spec" -- the final blueprint for the software is the written code, which is then compiled and runs as software in some environment.

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

Interfaces are a good example of OO code reuse, don't you think?

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

Or doFoo(z) where z = (x, y)

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

Yes, I have seen that the need to refactor Java code is higher than I would have thought and the ease in doing so is not as good as I would have liked.

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

OK, I see the point.

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

Yes, I can see that there are some things that are very brittle. I don't mind Java, however, in spite of my closet procedural bent (having started in the industry with FORTRAN, BASIC, and COBOL). Declarative is my least favorite language, based on "taste" not logic.

Cheers! --dawn Received on Wed Apr 14 2004 - 23:37:48 CEST