Re: Maintenance! (Re: Whose Fish - OO solution)

S Perryman wrote:
topmind wrote:

TM>Also, OO'ers *do* seem to hard-wire domain taxonomies into production
TM>app code or build non-trivial data structures into their app
TM>(reinventing the DB) such that textbook puzzles and their production
TM>OO style perhaps do not really differ that much. Martin's payroll
TM>hardwired concepts and taxonomies into his sample, for example. Thus,
TM>to them it seems like "home".

1. Completely irrelevant to this thread, which is : Whose Fish - OO solution.

2. Completely irrelevant to this thread, because the solution given by the
OP does not "hard-wire domain taxonomies into production app code or build
non-trivial data structures" .

It *is* relevant if their coding style for toy examples matches that
of production code.

Anyone with a semblance of intelligence will forego matters of coding style
for a solution that is correct and understandable.

Being understandable for a one-time homework problem and being
maintainable are not necessarily related. I don't know about your
code, but my one-time solutions look a lot different than my
"standing" app solutions.

A fact that applies to both the OOP and SQL solutions posted.

TM>Hit me with your best shot. I do make sloppy mistakes sometimes, but
TM>I'm rarely fundimentally wrong so far.

Don't have to. You killed yourself with your own sword by the very fact
that you have even talked about using counter-terrorism as an example.

The fact that you cannot even keep track of your self-contradictions (and
only 3 weeks ago at that) is just more evidence of the fact that you are an
embarrassingly poor debater.

If you can keep track of everything you've said 3 weeks ago, I applaud
your memory.

Well no, you write so much rubbish on comp.object, who can expect you to
remember what you wrote.

So I am prolific and forgetful. I have dandruf also, by the way.

But because it is the same old rubbish, you should
at least maintain a stock collection of said rubbish (perhaps even titled/
enumerated so you don't have to repost it) .

You should perhaps do the same with your OOP proof. Oh you did, and
its Zero bytes. How about that.

It is a good thing I forget stuff 3 weeks old, otherwise
I would broil over all the personal insults an accusations of lies and
fraud your hurl my way.

So you claim I have made statements that you a fraud (one who engages in
acts of deceit for material advantage/gain - financial traditionally) ??

IMHO claiming someone is a fraud is a far more serious matter than
claiming that they are a liar.

That probably depends on the person. Its like asking if you would
rather be kicked in the nuts or punched in the stomach.

Checking Usenet archives on comp.object for "perryman" "topmind" "fraud"
(and spelling variations on the latter ) ...

Oh guess what, the *only* message that matches the search terms ??
The posting to *which I am replying* .

So you have deliberately made a statement known to be untrue.
Therefore you are a liar.

For pete's sake, we've been over this already. One is not lying if THE
TELLER does NOT know it to be false. You could argue that I was
careless for not checking, but that is a different sin. To give
evidence of "lying", you would have to present evidence that I *knew*
during the writing of that statment that you never uttered that word.
Since you accused me of having a bad memory, you couldn't have
expected that I track every word ever written in my mind.

And, I meant "fraud-like behavior", not necessarily a the word
verbatim. You are conveniently switching back and forth from informal
conversation mode to lawyer mode to suit your own slander needs. IOW,
a fair-weather lawyer.

So you see:

1. comp.object doesn't have to have 3 weeks memory when it comes to
being reminded about your ways.

2. Liars need much better long-term memory, because they never know when
their lies are going to be challenged. and how (as I was taught from
knee-high : get your story straight) .

> (None objectively proven, by the way.)


You are using the wrong definition of "liar". Otherwise "Dorry" on
Finding Nemo would be a massive "liar" by your def. Even the cartoons
prove are full of animated sh8t.

TM>It was mostly a sarcistic joke.

1. Sarcastic, not sarcistic (you cannot even blame keyboard layout) .
2. Not a good joke.
3. It backfired on you.

If YOU liked it, I would really be shocked. I expect you to dispise
everything I say and do by now. It is thus unnecessary to report that
you hate my jokes. Itsa given.

Reporting the facts != hatred.

Calling people names similar to stupid or dummy is not "fact", unless
you can reverse engineer their neurons and show where the faulty
circuits are.

Why are you bleating on about the requirements in Robert Martins' payroll
example !!??

The topic of this thread is : Whose Fish - OO solution.
Not Robert Martins' employee payroll processing example.

Somebody ASKED how I would add a YTD union fee limit. You clipped it
out. (BTW, I've found a simpler way to add it since the above, if
anybody's interested.)

No they didn't.
It was *I* who gave you a *suggestion* as to what kind of questions a
payroll variant of the "Whose fish" problem might be expected to answer.

If that was the case, I misinterpreted your question and I apologize.

So are you going to define a set of facts (in the format of the "Whose
fish" problem) for the payroll domain, and then set us the questions that
you want people to provide solution implementations for ??

Didn't YTD qualify as one? You appear to be contradicting yourself.
You seem to be rejecting your own example.

Okay then, how is the problem going to change over time? Let's explore
change scenarios for Fish.

Fair enough. Give us the change scenarios that you wish to discuss.

I cannot do it for a toy example. I don't live in Toyland. I don't
know the rules of that universe. Giant magnets pull the Road Runner? I
am only familiar with reality.

TM>Without understanding something about the domain, it is hard to
TM>explore change patterns and their impact on the code.Will they always
TM>being dealing with fish, cigaretts, and houses, or will the nouns
TM>change? Who will enter/create the new nouns? Who will classify them?
TM>Will other apps share info about them? These are KEY questions for
TM>most apps that I've analyzed. Do you disagree?

Then provide a "real world" domain for an example.
The premise is very simple :

For some "real world" domain, devise a set of facts for that domain for
which some question can be asked. Then solicit solutions in s/w that will
answer the question with a given set of facts.

We already did that with the payroll example.

Robert Martins' payroll example is nothing of the kind.

Please clarify. Do you mean Prolog-like logic questions?

If you cannot do even expend effort on that front, don't expect anyone
to even bother with your suggestions for a "real world" example.

You keep trying different examples until you find one that can bust P/R?


1. For the topic of this thread, OOP and SQL solutions have been given.
People on comp.object appear to be quite happy to discuss them.

I'm not stopping them. Im just complaining that it is not known how to
provide realistic change scenarios to toy problems. If you wish to use
some other criteria other than change scenarios, be my guest. Nobody
wants to suggest such. That is not my problem. If you don't like my
metrics, then GIVE AN ALTERNATIVE. Complaining is easy when you don't
have to give an alternative.

2. It is *YOU* who wants to try "different examples" , not us.

The "Whose fish" problem is sufficiently representative of a type of
problem in the real world for which systems are built to solve. Fortunately
there are enough people here with sufficient intelligence to realise this

I guess I am just dumb and you see stuff in that problem that I don't.
However, you are really bad at articulating what "it" is.

3. Because of your embarrassingly poor ability to remember what you have
written, or bother to check before you post here, your suggested choice of
"real world" example has made you look even more stupid.

Everything I do will end up looking "stupid" in your eye. I am
perfectly satisfied that my version of Payroll makes Martin's version
look like a bloated, hardwired mess. Your insults will not change that

TM>If the issue is something other than MAINTAINABILITY, then please
TM>state so.

Still wating...

Your usual cowardly attempt to evade something when the limits of your
intelligence/ability swoop into view.

The issue is about providing solutions to the "Whose fish" problem.

If maintenence be damned then it TRUELY is not a realistic example for
the vast majority of apps. I rest my case. How about a cryptic Perl
one-liner solution?

Reached rock-bottom again, and still digging (sigh) .
Any "cryptic" solution can be cosmetically changed into a more readable/
understandable form. A solution is *invariant* under cosmetic change.

Ah, "readable". Okay, there's a potential metric other than
maintainability. So, how does one measure that to avoid subjectivity

Steven Perryman