Re: Databases as objects
- From: "topmind" <topmind@xxxxxxxxxxxxxxxx>
- Date: 27 Dec 2006 13:54:41 -0800
S Perryman wrote:
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.
How come the claimer of "motivation" is not subject to your page-number
citation harassment also? Dare I say, "double standard"? You jumped
right over their claims. How convenient. Proof right here of your
double standards. Your friends can be sloppass, but I cannot.
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) .
That is unrealistic. The boundaries a somewhat fuzzy. What are you
implying? BTW, I've given some suggestions that readers can relate to:
student grade tracking and airline reservations.
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.
The default is not OO.
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.
I never claimed they were objectively superior. I believe paradigm
benefits are probably subjective. There are many roads to the same
solution and people pick what best fits their head.
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.
Pro-OO's haven't either. Show me specifics where procedural/relational
is objectively worse in biz apps (and not language-specific faults).
Double Standard.
- construct a decent example that illustrates a specific problem that
you claim exists.
Same with you with regard to procedural/relational. D.S. again.
but OO is not proven better outside of systems software.
Is OO is proven better *inside* of systems software ??
I did not claim that. I am only saying I am not challenging OO in
systems software. You read what you want to read, not what is actually
there. More evidence that your dislike of me distorts your view of
reality.
Steven Perryman
-T-
.
- Follow-Ups:
- Re: Databases as objects
- From: S Perryman
- Re: Databases as objects
- References:
- Re: Databases as objects
- From: topmind
- Re: Databases as objects
- From: Patrick May
- Re: Databases as objects
- From: topmind
- Re: Databases as objects
- From: Patrick May
- Re: Databases as objects
- From: topmind
- Re: Databases as objects
- From: Patrick May
- Re: Databases as objects
- From: topmind
- Re: Databases as objects
- From: S Perryman
- Re: Databases as objects
- From: topmind
- Re: Databases as objects
- From: S Perryman
- Re: Databases as objects
- Prev by Date: Re: avoid cast to derived
- Next by Date: Re: BOUML : a free UML toolbox for Windows, Linux and MacOS X
- Previous by thread: Re: Databases as objects
- Next by thread: Re: Databases as objects
- Index(es):
Relevant Pages
|