Whose Fish - OO solution

S Perryman wrote:
> topmind wrote:
>
> > S Perryman wrote:
>
> TM>I was thinking of a way to make this problem more real-world instead
> TM>of textbook-puzzle-ish. One possible application would be crime
> TM>solving, or perhaps terrorist tracking.
>
> >>You were told by me, last month, that the problem had real world
> >>application in anti-terrorist intelligence (posted on May 10th) .
>
> > I don't recall that, but if that was the case, then why not *present*
> > an anti-terrorism problem, and give some sample scenarios? That way we
> > don't *have to* deal with a text-book-puzzle-like problem. Cut out
> > the middle-man.
>
> It is you who wants to make the problem different.
> Everyone else seems quite happy with the original problem.

Is it because they feel it is a good paradigm comparison project, OR
merely because it is "fun" to them? I don't have an answer to that.

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

Also, perhaps being a glorified product taxonomy clerk dressed as a
programmer is appealing to them or is great job security. (I am not
saying I know for sure, I am just asking.)

Textbook puzzles often neglect info sharing issues (such as DB's) and
maintainence inssues. (More on this below.)

>
> So feel free to redefine the problem in *any form that you wish to make* .
>
>
> >>Can you guess what your reply (posted on May 22nd) was to this fact ... ??
>
> > Nope. Let's hope it won't embarass me, however :-)
>
> Forelorn hope (and quite embarrassing) .

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

>
>
> TM>(Instead of "who has the fish", the questions may resemble, "who may
> have a bomb".)
>
> >>Feel free to change the example (and all the facts) to something else.
>
> > Okay, how about a payroll example!
>
> Fine. Provide a payroll-based version of the "Whose fish" problem.
> I expect the 'question' to be something akin to :

It was mostly a sarcistic joke.

>
> Who is not required to pay union dues for the rest of the year because of
> their contributions made to date ??
>
> And facts akin to :
>
> union-member(fred)
>

It should be clear from my online documentation how "membership" is
done. As far as reaching a contribution limit, a Year-to-Date table
could be created and the union fee amount for that employee in the
EmpCharges be zeroed out or reduced. My app is not meant to directly
perform such a task as is[1], but custom processes could be created
for it using *any* language of choice that has ODBC access to the
tables. They don't have to do it in the app's native language. This is
one of its selling points. (I assumed a SAP-like arrangement where
customized client-specific processes can be created for each customer
instance.)

In fact, almost anybody reasonably familiar with MS-Access could whip
out such a YTD threashold add-on in a few hours (all without knowing
squat about the app's native language).

[1] YTD calcs and threasholds were not part of Martin's original
requirements that I know of. Perhaps they should be added to a real
package because they are fairly common. And I did note in my doc that
I purposely did not include the period-end processing.

(Note that being a member {of union} in general and being a "member"
for the purposes of payroll may differ. I've found that "master"
tables of anything tend to have this problem: each department has
enough differences and exceptions that it is often better for each
department to track their own mappings. I've created 3 different views
of organizational structure at some places multiple times. A one-size-
fits-all generic "master" is rarely sufficient, especially if the DBA
is often busy.)

>
> >>I would suggest going to the site from where the "Whose fish" example came.
> >>IIRC the site had a collection of similar problems. One of those may save
> >>you the effort of having to construct a "real world" example.
>
> > It is not my job to cull problems to present to comp.object. I already
> > did a few and posted the source code on the web. Nobody has shown it
> > objectively worse than Martin's version(s).
>
> 1. Robert Martin AFAIK has not provided an implementation of the "Whose
> fish" problem. If I am mistaken, feel free to tell us where his impl may be
> found.

I am saying that I already supplied code for given examples. It was
Robert's suggestion that I take a look at the examples in his book,
and I forked over money for the book. I am not obligated to supply a P/
R version for every example presented on comp.object!

>
> 2. You want to discuss a "terrorist" variant of the problem, but you don't
> want to provide the information that will enable that variant to be
> defined.
>
> (Predictably) lazy.

I have already presented applications with source code. A terrorist
hunting system makes for a interesting problem though. But I cannot
whip out requirements any time soon. The FBI spent gajillion dollars
on such and still can't get a decent one.

>
>
> 3. You have been directed to a site that may have examples that you can
> quickly convert into a problem that you wish to make, thus saving you time/
> effort. But you don't want to do even that.
>
> (Predictably) lazy.
>
>
> >>What does the SQL solution that was posted now look like without
> >>"hard-wired" schema information ??
>
> > I wanted to settle on a less "puzzly" version of the example so that I
> > could explore this issue of how "meta" it would need to be.
>
> As "meta" as one desires.
> The SQL and OOP solutions solved the specific problem.

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

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

>
> If you wish to change the problem to one where any facts can be stated,
> and any question can be asked, feel free to do so.
>
>
> >>An OO impl of a FOPL engine, vs a "P/R" one.
> >>It will be interesting to see your implementation of such an engine.
>
> > FOPL? Functional?
>
> First-order predicate logic.
> Actually the problem is FOPL, with CWA ( "closed world assumptions" ) .

Okay, it might be interesting, but that is kind of a "systems
software" domain (basic or non-domain-specific boxed tools). I never
disputed OO in systems software. (Systems software is things like OSs,
compilers, GUI frameworks, RDBMS engines, etc.)

>
>
> Regards,
> Steven Perryman

-T-

Kreeg wrote:
> topmind wrote:
> > Kreeg wrote:
> >> topmind wrote:
> >>> Jordan Marr wrote:
> >>>> I never posted my solution to Whose Fish, and since my old thread
> >>>> probably has a stigma attached to it, I'll post it here.
> >> ** SNIP Jordan's original post **
> *SNIP*
> >
> >> However, an inference engine would certainly be an interesting way of
> >> solving the problem, I think.
> >
> > Perhaps that would just be reinventing Prolog :-)
> >
> **SNIP **
> >>
> >> The most interesting piece of this problem IMO is not how the houses,
> >> people, and streets get entered, but how the program goes about finding
> >> the correct answer given sets of these things and a set of rules.
> >
> > Again, It would be interesting to see a Prolog solution in the sense
> > you tell it the logic rules and then ask questions over those rules.
> >
>
> I agree.

(begin matyr syndrom)
Agreeing with me will get you flogged around here.
(end matyr syndrom)

> I personally couldn't provide a Prolog implementation because
> I've never used it, but I would think that an implementation using any
> Rules Engine would be similar. Or did I mis-read the Wikipedia article
> on Prolog that I had to look up? :-P
>
> >>> It always seemed to me that if you remove domain classification from
> >>> app code, the result will not be very OOP. There would be little or no
> >>> need for inheritence or polymorphism. If you disagree, I would like to
> >>> understand why, with perhaps some examples.
> >>>
> >> Heck, Jordan's solution has very little inheritance or polymorphism.
> >> That doesn't mean I don't think it's a perfectly valid approach.
> >
> > My comment was about the matter of being OO versus not being OO, not
> > necessarily "valid" or not. Jordan's solution is not that OO. It
> > mostly only uses encapsulation, not the other two. That is, the
> > operations and data structures are bound together in the OO "self-
> > handling-noun" way. Thus, on a continious scale, it has a fairly low
> > amount of "OO-ness" if you will.
> >
>
> This is true. It actually gets back to Steven Perryman's comment to you
> that you that you would be 'pleasantly surprised' to see that OO
> probably doesn't add much to this particular problem over a straight
> procedural solution.

Then why is he and others pressing the issue? Why not hunt for a biz
problem where OO kicks tail? Chock full of glorious polymorphism. That
would make everyone happy. Is he just yanking me around for the sake
of yankage?

>
> I'd also be pretty interested in a solution that used C# 3.0's LINQ.
> There are some pretty neat things that have been done with LINQ just for
> the fun of it. [2]
>
> [2]
> http://blogs.msdn.com/lukeh/archive/...-in-c-3-0.aspx
>
> >> [1] http://groups.google.com/group/comp....c9e241f760a89a
> >

-T-

topmind wrote:

> S Perryman wrote:

TM>I was thinking of a way to make this problem more real-world instead
TM>of textbook-puzzle-ish. One possible application would be crime
TM>solving, or perhaps terrorist tracking.

SP>You were told by me, last month, that the problem had real world
SP>application in anti-terrorist intelligence (posted on May 10th) .

TM>I don't recall that, but if that was the case, then why not *present*
TM>an anti-terrorism problem, and give some sample scenarios? That way we
TM> don't *have to* deal with a text-book-puzzle-like problem. Cut out
TM> the middle-man.

>>It is you who wants to make the problem different.
>>Everyone else seems quite happy with the original problem.

> Is it because they feel it is a good paradigm comparison project, OR
> merely because it is "fun" to them? I don't have an answer to that.

Both (IMHO) .


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


SP>Can you guess what your reply (posted on May 22nd) was to this fact ... ??

TM>Nope. Let's hope it won't embarass me, however :-)

>>Forelorn hope (and quite embarrassing) .

> Hit me with your best shot. I do make sloppy mistakes sometimes, but
> 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.


SP>Feel free to change the example (and all the facts) to something else.

TM>Okay, how about a payroll example!

>>Fine. Provide a payroll-based version of the "Whose fish" problem.
>>I expect the 'question' to be something akin to :

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


> [1] YTD calcs and threasholds were not part of Martin's original
> requirements that I know of. Perhaps they should be added to a real
> package because they are fairly common. And I did note in my doc that
> I purposely did not include the period-end processing.

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.

If, as I have suggested, you wish to make a version of the "Whose fish"
problem that is based in the domain of employee payrolls, feel free to do
so.


>>1. Robert Martin AFAIK has not provided an implementation of the "Whose
>>fish" problem. If I am mistaken, feel free to tell us where his impl may be
>>found.

> I am saying that I already supplied code for given examples. It was
> Robert's suggestion that I take a look at the examples in his book,
> and I forked over money for the book. I am not obligated to supply a P/
> R version for every example presented on comp.object!

I will ask you again :

Has Robert Martin engaged in providing a solution to the "Whose fish"
problem ??

The answer is either yes or no.


>>2. You want to discuss a "terrorist" variant of the problem, but you don't
>>want to provide the information that will enable that variant to be
>>defined.

>>(Predictably) lazy.

> I have already presented applications with source code.

I am not interested in these "presented applications" for other topics.
I (as do no doubt others) have interest in the topic of this thread.
which is : Whose Fish - OO solution


> A terrorist hunting system makes for a interesting problem though. But I
> cannot whip out requirements any time soon.

(Predictably) lazy.


TM>I wanted to settle on a less "puzzly" version of the example so that I
TM>could explore this issue of how "meta" it would need to be.

>>As "meta" as one desires.
>>The SQL and OOP solutions solved the specific problem.

> Most of the claims made about OOP involve it being easier to change.

The topic is : "Whose Fish - OO solution" .


> Without understanding something about the domain, it is hard to
> explore change patterns and their impact on the code.Will they always
> being dealing with fish, cigaretts, and houses, or will the nouns
> change? Who will enter/create the new nouns? Who will classify them?
> Will other apps share info about them? These are KEY questions for
> 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.

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.


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

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.
Not about MAINTAINABILITY.


TM>FOPL? Functional?

>>First-order predicate logic.
>>Actually the problem is FOPL, with CWA ( "closed world assumptions" ) .

> Okay, it might be interesting, but that is kind of a "systems
> software" domain (basic or non-domain-specific boxed tools). I never
> disputed OO in systems software. (Systems software is things like OSs,
> compilers, GUI frameworks, RDBMS engines, etc.)

Another usual cowardly attempt to evade.
The "Whose fish" problem is not "systems software" .


Regards,
Steven Perryman

topmind wrote:

> Kreeg wrote:

TM>My comment was about the matter of being OO versus not being OO, not
TM>necessarily "valid" or not. Jordan's solution is not that OO. It
TM>mostly only uses encapsulation, not the other two. That is, the
TM>operations and data structures are bound together in the OO "self-
TM>handling-noun" way. Thus, on a continious scale, it has a fairly low
TM>amount of "OO-ness" if you will.

>>This is true. It actually gets back to Steven Perryman's comment to you
>>that you that you would be 'pleasantly surprised' to see that OO
>>probably doesn't add much to this particular problem over a straight
>>procedural solution.

> Then why is he and others pressing the issue? Why not hunt for a biz
> problem where OO kicks tail? Chock full of glorious polymorphism. That
> would make everyone happy. Is he just yanking me around for the sake
> of yankage?

Feel free to tell us what "issue" you believe I am "pressing" .


Regards,
Steven Perryman

topmind wrote:
*** MASS SNIPPAGE ***
>
> Then why is he and others pressing the issue? Why not hunt for a biz
> problem where OO kicks tail? Chock full of glorious polymorphism. That
> would make everyone happy. Is he just yanking me around for the sake
> of yankage?
>

Please go back to the original post of the original 'Whose Fish' thread,
by Jordan Marr. Here it is for you, in fact.

http://groups.google.com/group/comp....0ff58ddddb8329

Mr. Marr actually states that he thinks that the 'Whose Fish' problem
would be a *great* problem to throw at a relational database, and wanted
to honestly see an implementation of it. However, you dismissed the
problem out of hand, and things degenerated from there.

As to why the 'Whose Fish' threads aren't about 'hunting for a biz
problem where OO kicks tail', 1.) Not every thread is about you, and 2.)
Not everyone here is on a crusade like you are. Maybe he just thought
it was an interesting problem, regardless of whether it furthered some
imaginary 'pro-OO' cause?

>> I'd also be pretty interested in a solution that used C# 3.0's LINQ.
>> There are some pretty neat things that have been done with LINQ just for
>> the fun of it. [2]
>>
>> [2]
>> http://blogs.msdn.com/lukeh/archive/...-in-c-3-0.aspx
>>
>>>> [1] http://groups.google.com/group/comp....c9e241f760a89a
>
> -T-
>

Jordan Marr wrote:
> > > Heck, Jordan's solution has very little inheritance or polymorphism.
> > > That doesn't mean I don't think it's a perfectly valid approach.
>
>
> > My comment was about the matter of being OO versus not being OO, not
> > necessarily "valid" or not. Jordan's solution is not that OO. It
> > mostly only uses encapsulation, not the other two. That is, the
> > operations and data structures are bound together in the OO "self-
> > handling-noun" way. Thus, on a continious scale, it has a fairly low
> > amount of "OO-ness" if you will. A "direct" procedural solution would
> > not be much different except that the data structures would be
> > "naked". (Whether this is good or not will take us back to the ol'
> > database versus app-RAM fights.)
>
> Inheritance allows my noun entities (house & street) to adopt the
> validation rule functionality from EntityBase. EntityBase, while not
> shown here, is composed of a few other custom classes, and delegates
> some behavior to them. There is also a hierarchy of Rule object
> defined that allows me to enter rules with or without "groups".
> Polymorphism is used here, behind the scenes, because my BrokenRule
> engine works with Rule objects, but it doesn't know or care what kind
> of Rule it is using. So if I am creating an entity with 20+
> validation rules, I may want the ability to display a list of broken
> rules by group. If so, I add GroupRule objects instead, using the
> "AddGroupRule" method on EntityBase. The fact that all that is
> encapsulated away makes the final app code and entity code all the
> more simple.
> All you see is "AddRule(...)" or "AddGroupRule(...)" in the Entity
> code. Or for that matter, I have a generic AddRule that simply takes
> a Rule object (of any kind). AddRule(new GroupRule(...)).
>
> So Polymorphism is available behind the scenes, but is encapsulated
> away, out of sight. It is not used in the application portion of the
> example (it wasn't required). However, I don't think there is any
> rule that says an OO program must incorporate all of these features to
> be considered OO. Those features are simply there if you need them
> for a given problem.

Do you agree that if there are many such nouns and many groups and
many rules, that tracking and organizing them in a database would be
more efficient? That way you could use off-the-shelf tools to add,
change, delete, search, sort, and report on what has what feature,
what has what relationship, and what belongs to which set. (And if
there is *not* very many, then which paradigm is used doesn't matter
much anyhow.)

I tend to use a "subtractive" approach to designing or at least
studying assocations between things. One starts off with the
assumption that *every* noun can have *every* feature (of app) and
every relationship. If some combinations are not allowed, then one
uses validation rules to prevent them. This makes the system more
flexible because one does not have to add or change code to get new
associations, but merely remove/disable the validation that prevents
it. New assocations then are virtually "free": little or no coding
changes.

Of course in practice going all the way down this route makes the
system run really slow such that compromises are made and somewhat
arbitrary boundaries are drawn. But as computers get more and more
powerful, a meta-centric approach gets more and more realistic. It can
become a giant Set Theory engine with coded hooks.

OOP, on the other hand, seems to use the additive approach: you
manually add relationships as encountered. I find it easier to remove/
disable a "not permitted" rule than to code for new relationships,
because the framework is already there. Removing a road-block is
easier than building a new road.

Further, the subtractive approach allows one to *delay association
decisions*. You code the features and test them, and *then* add the
associations and validation as mostly meta data, perhaps with the help
of a domain expert clerk.

Inheritence is not powerful enough to do subtractive modeling well
because it is mostly tree-bound instead of set-bound, and polymorphism
puts all the references betwen things in app spehgetti app code
instead of the DB where it is easier to add, change, delete, search,
sort, report, etc. App code makes for a sh8tty database of attributes
and relationships, especially as you scale.

(One should also include lots of "hooks" such that declarative stuff
can be tweaked at given key events with app code. Not everything can
be done declaratively, but with hooks one can make say 80 to 90% of it
declarative, yet allow custom coded tweaks where needed. It takes on
the characteristics of an event-driven design.)

>
> Jordan

-T-

On Jun 12, 6:29 pm, Kreeg <k...{}sentdotcom.nospam> wrote:
> topmind wrote:
>
> *** MASS SNIPPAGE ***
>
>
>
> > Then why is he and others pressing the issue? Why not hunt for a biz
> > problem where OO kicks tail? Chock full of glorious polymorphism. That
> > would make everyone happy. Is he just yanking me around for the sake
> > of yankage?
>
> Please go back to the original post of the original 'Whose Fish' thread,
> by Jordan Marr. Here it is for you, in fact.
>
> http://groups.google.com/group/comp....0ff58ddddb8329
>
> Mr. Marr actually states that he thinks that the 'Whose Fish' problem
> would be a *great* problem to throw at a relational database, and wanted
> to honestly see an implementation of it. However, you dismissed the
> problem out of hand, and things degenerated from there.
>
> As to why the 'Whose Fish' threads aren't about 'hunting for a biz
> problem where OO kicks tail', 1.) Not every thread is about you, and 2.)
> Not everyone here is on a crusade like you are. Maybe he just thought
> it was an interesting problem, regardless of whether it furthered some
> imaginary 'pro-OO' cause?
>
>
>
> >> I'd also be pretty interested in a solution that used C# 3.0's LINQ.
> >> There are some pretty neat things that have been done with LINQ just for
> >> the fun of it. [2]
>
> >> [2]
> >>http://blogs.msdn.com/lukeh/archive/...racer-in-c-3-0....
>
> >>>> [1]http://groups.google.com/group/comp.object/msg/cec9e241f760a89a
>
> > -T-- Hide quoted text -
>
> - Show quoted text -

I have nothing further to add, your honor.

S Perryman wrote:
> topmind wrote:
>
> > S Perryman wrote:
>
> TM>I was thinking of a way to make this problem more real-world instead
> TM>of textbook-puzzle-ish. One possible application would be crime
> TM>solving, or perhaps terrorist tracking.
>
> SP>You were told by me, last month, that the problem had real world
> SP>application in anti-terrorist intelligence (posted on May 10th) .
>
> TM>I don't recall that, but if that was the case, then why not *present*
> TM>an anti-terrorism problem, and give some sample scenarios? That way we
> TM> don't *have to* deal with a text-book-puzzle-like problem. Cut out
> TM> the middle-man.
>
> >>It is you who wants to make the problem different.
> >>Everyone else seems quite happy with the original problem.
>
> > Is it because they feel it is a good paradigm comparison project, OR
> > merely because it is "fun" to them? I don't have an answer to that.
>
> Both (IMHO) .
>
>
> > Also, OO'ers *do* seem to hard-wire domain taxonomies into production
> > app code or build non-trivial data structures into their app
> > (reinventing the DB) such that textbook puzzles and their production
> > OO style perhaps do not really differ that much. Martin's payroll
> > hardwired concepts and taxonomies into his sample, for example. Thus,
> > 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.

>
>
> SP>Can you guess what your reply (posted on May 22nd) was to this fact ... ??
>
> TM>Nope. Let's hope it won't embarass me, however :-)
>
> >>Forelorn hope (and quite embarrassing) .
>
> > Hit me with your best shot. I do make sloppy mistakes sometimes, but
> > 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. 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. (None objectively proven, by the way.)

>
>
> SP>Feel free to change the example (and all the facts) to something else.
>
> TM>Okay, how about a payroll example!
>
> >>Fine. Provide a payroll-based version of the "Whose fish" problem.
> >>I expect the 'question' to be something akin to :
>
> > 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.

>
> > [1] YTD calcs and threasholds were not part of Martin's original
> > requirements that I know of. Perhaps they should be added to a real
> > package because they are fairly common. And I did note in my doc that
> > I purposely did not include the period-end processing.
>
> 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.)

> TM>I wanted to settle on a less "puzzly" version of the example so that I
> TM>could explore this issue of how "meta" it would need to be.
>
> >>As "meta" as one desires.
> >>The SQL and OOP solutions solved the specific problem.
>
> > Most of the claims made about OOP involve it being easier to change.
>
> The topic is : "Whose Fish - OO solution" .

Okay then, how is the problem going to change over time? Let's explore
change scenarios for Fish. What? Can't for a toy example because
nothing is real? Ohhh, that's sooo sad. Me weeps. Strawberry fields
forever.

>
>
> > Without understanding something about the domain, it is hard to
> > explore change patterns and their impact on the code.Will they always
> > being dealing with fish, cigaretts, and houses, or will the nouns
> > change? Who will enter/create the new nouns? Who will classify them?
> > Will other apps share info about them? These are KEY questions for
> > 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.

>
> 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? That technique will certainly eventually work because P/R is not
always the best solution for biz apps, only usually the best (or at
least not objly. worse). If you run enough horses, your horse will
eventually win out of shear numbers.

>
>
> > If the issue is something other than MAINTAINABILITY, then please
> > state so.
>
> 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.
> Not about MAINTAINABILITY.

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?

>
>
> Regards,
> Steven Perryman

-T-

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

Potmind,

Not all apps require metadata and user configurability. While it may
be possible to turn this app into a "one size fits all", "solve any
problem" app, that does not seem like an effecient use of time to do
so, IMO. It's finished and it perfectly solved the problem. If the
problem shifts, I can easily modify my logic and it would be adapted
and ready. Done deal!

Right now the attributes are hard coded into enums. So then lets put
them all into tables. That could be done -- very easily -- but what
would we gain? We'd still have the business logic (rules) in the
code. So let's say we take the rules out of the code and put them
into the database as well. How would we be able to express the rules
in a way that was completely user configurable (not hard coded)? We
would have to write a rule logic-building interface for the user to
enter rules and attributes. That's great, and I have seen systems
like this that allow users to enter in code-like logic. But the
systems are usually clunky, and basically a bad way to reproduce what
code was intended to do. Coding is the more eloquent way to provide
this kind of business logic. And this is a widely accepted practice
in businesses all over the world. Even if the user's could enter in
rules, I still don't know how it would work as a one size fits all
app.

I think you are just trying to add requirements to an otherwise cut-
and-dried problem in an attempt to find a way to steer it into your
idiotic argument blender.



Jordan

Jordan Marr wrote:
> > It *is* relevant if their coding style for toy examples matches that
> > of production code.
> >
>
> Potmind,

Insult detection notice.

>
> Not all apps require metadata and user configurability.

We don't know what the typical changes and future needs are, period.

> While it may
> be possible to turn this app into a "one size fits all", "solve any
> problem" app, that does not seem like an effecient use of time to do
> so, IMO. It's finished and it perfectly solved the problem. If the
> problem shifts, I can easily modify my logic and it would be adapted
> and ready. Done deal!

Showing mere executability does not tell us much. Most of the
braggings about OO revolve around making maintenence easier. If you
are demonstrating something else, such as less lines of code or the
pretty flower shape it makes when printed out, please clarify what you
are betterfying. What exactly is broke and what exactly is OO fixing?

>
> Right now the attributes are hard coded into enums. So then lets put
> them all into tables. That could be done -- very easily -- but what
> would we gain? We'd still have the business logic (rules) in the
> code. So let's say we take the rules out of the code and put them
> into the database as well. How would we be able to express the rules
> in a way that was completely user configurable (not hard coded)? We
> would have to write a rule logic-building interface for the user to
> enter rules and attributes. That's great, and I have seen systems
> like this that allow users to enter in code-like logic. But the
> systems are usually clunky, and basically a bad way to reproduce what
> code was intended to do.

Maybe they did it wrong. I cannot see without inspecting the code. Nor
do I propose it for all apps. But IF the main criteria is adding/
changing features with the fewest code changes, then meta-tizing stuff
is often the best way to go. I don't always think that is the utmost
important criteria myself, but OO'ers seem to emphasize it and to
compete with those rules, metatizing works well. Sometimes is hurts
KISS, but they are not consider that. P/R can bend either way. In
practice I tend to use a different balance of criteria for "good code"
than merely changing the fewest lines of code per change request. Its
just that if OO'ers frame the battle in terms of changed code
quantity, meta-tizing is nice weapon to play under that weighting of
the "game". If you say P/R cannot do X, I may show it doing X to prove
you wrong even if doing X is not the most important in practice.

> Coding is the more eloquent way to provide
> this kind of business logic.

I have to disagree. Some parts are and some are not. (Note that there
is a middle ground between programmer-configured and user-configured.)

> And this is a widely accepted practice
> in businesses all over the world. Even if the user's could enter in
> rules, I still don't know how it would work as a one size fits all
> app.
>
> I think you are just trying to add requirements to an otherwise cut-
> and-dried problem in an attempt to find a way to steer it into your
> idiotic argument blender.
>

No, I am trying to describe why it is a poor representive of real
work. Perhaps I failed, but I did try.

>
>
> Jordan

-t-