Re: Databases as objects

topmind wrote:

S Perryman wrote:

topmind wrote:

PM>You've got it backwards. You used the Visitor pattern in
PM>support of one of your claims in your conversation with Neo. I
PM>simply pointed out that it does not, in fact, support your
PM>argument. The burden of proof is still on you to provide an
PM>example of OO techniques leading to "tangled pasta".

TM>There are no real rules for when to use what GOF pattern, especially
TM>if there are competing factors. The rules of relational
TM>normalization are governed mostly by duplication removal. All else
TM>being equal, consistency trumps inconsistency.

PM>So you can't provide an actual example. You should just come out
PM>and say so.

TM>How exactly does one provide examples to show that there are no
TM>consistent consensus rules for something?

I contend that GoF have such rules: they are labelled "motivation" etc .

They are often worded as "adding an X without having to change Y".

Please give us an exact reference to all the GoF patterns that are
worded in the manner that you claim.

Page numbers in the GoF book would be most helpful. Failing that, the
pattern names will suffice.


> However, change needs often change over time. Up-front change needs
> are often not a good guide to future change needs.

???

What is a "change need" ??
And once you have explained this, what is an "upfront" / "future"
change need ??


Okay, I declare "tangled pasta" a subjective opinion.

And how many postings from Patrick May et al has it taken you to
admit this obvious (to us anyway) fact ??


Until they are proven better in my domain

And what precisely is your "domain" ??

I expect *specific* infomation here (on-line shopping catalogues, share
dealing systems, inventory control etc) .



with inspectable public
source code, I shall use procedural/relational techniques instead and
recommend others ignore them also.

A recommendation that by your own admission is based on opinion and not
fact.


So, as far as GoF patterns go (and using your weird language) :

show us *one* "inconsistent consensus rule" .

It is *your burden* to show that one condition.

If you cannot, as Patrick May has so amusingly had you squirming over
the months on various different threads trying to avoid, state that
while you have doubts as to the veracity of something, you specifically
do not have the proof (and/or ability) to disprove the veracity.

The bottom line is that you cannot prove GOF OO better.

Pick a GoF pattern, and we can construct an example that you can use to
illustrate that your preferred development methods are superior to.



Mr. May likes
nitty side-tracks to distract from the real issue. He is more
interested in bashing me than in defending OO.

He has done no such thing.
He has on numerous occasions easily forced you into a corner.

Specifically, that you cannot :

- cite any personal real-world experience of working on OO projects
where a problem you claim exists can be explained to us by example.

- construct a decent example that illustrates a specific problem that
you claim exists.



Kick the messenger all you all want

No need. You do a sterling job in kicking yourself.


but OO is not proven better outside of systems software.

Is OO is proven better *inside* of systems software ??



Whether I am a genious or Bozo, you still have no OO proof.

See above.


Regards,
Steven Perryman
.