Subj : Re: Polymorphism sucks [Was: Paradigms which way to go?]
To   : comp.programming,comp.object
From : topmind
Date : Thu Sep 22 2005 11:24 pm



>
> > For example, the function calls. They bust your damned tree
> > into a graph yet you refuse to acknolege that.
>
> If you actually understood what a run time call graph was you'd
> realize instantly it's a tree--even a pure tree by your twisted
> definition of "pure tree".


NOT! It has to turn reference into duplicate nodes to force tree-ness.
Normalized, it would NOT be a tree.  If you don't see the duplication,
you are stubborn or blind.


>
> But since you never did understand it, the best you can do is
> act like a 12-year-old:

A 12-year-old who happens to be correct. Neener neener tree f8ck!

> >> and don't understand the value of trees--particularly as data
> >> structures.
> >
> > Until I see them donstrated to have real value in my domain, I
> > will avoid them except on a small scale.
>
> As I've said before, for a report writer--as opposed to a real
> programmer--there probably ISN'T much value in tree-shaped taxonomies,
> although there might be in tree-shaped data.  I know I've created
> reports that returned hierarchical data.  Perhaps you never have.


The hierarchical nature of such reports is a particular *view*. The
arrangement of the tree can often be changed. For example, one can nest
products sold by region, or regions per product.

  Region A
     product 1
     product 2
     product 3
  Region B
     product 1
     product 2
     .....

OR

  Product 1
    region A
    region B
    region C
  Product 2
    region A
    ...

In the old days (read about IMS) the databases hard-wired the
hierarchies into its structure. If a particular report was by the same
tree, it was okay. If not, you had to bend over and scratch your back
with your tongue.


> >> Exactly.  And a huge amount of it is.  My group deals with a major
> >> application *designed* for businesses to use out of the box.
> >
> > Why not point us to its website?
>
> All our installations are internal, so you can't access ours, but if
> you go ogle for major CRM vendors and pick the top one, you'll probably
> have it.

I have worked with the databases of companies that have tens of
millions of customers, and generally they base their classification
systems on sets. In fact, some of the biggest problems happened from
hierarchical arrangments set up in the days when they were much
smaller. The trees failed to scale and they had to overhaul them. For
example, they are shifting from "levels" to prequisites based on sets
to match which products must be sold together. Levels were sufficient
when their product base was small. However, customers want more
al-la-carte choice.


>
> > Your "event-driven" startup drivel was laughable.
>
> Failing to understand it, you laugh at it.  Typical.
>
> > You conveniently redefined "sequence" as being hierarchical.
> > "A" happening before "B" does NOT make anything hierarchical.
>
> Which just demonstrates how badly you misunderstood the example.
> As I recall, I had to explain several times before you even got
> close to an understanding, but close was the best you could do.


Let's leave it to the reader to decide whither sequences are
hierarchical. I am tired of debating somebody who cannot show inharent
treeness but insist it is there. I will agree that one *can* implement
start-up events as a hierarchy. But it is *not* the only way, and not
the way I would choose.


>
> Why am I bother to explain this to someone who apparently doesn't even
> grasp basic set theory (or at least whined about intimidation when I
> challenged you)?
>
> But, once more, sets are fine when the data
> is sequential or unordered...

You just don't get it. It is not that they are "unordered", it is that
they don't hard-wire in ONE-and-only-one order, because the "proper"
viewpoint is relative to user needs rather than universal. Relational
is the best known relativity tool out there.


> --
> |_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |

-T-

.