From: Robert Klemme <bob.news@...>
Date: 2003-09-13T00:57:24+09:00
Subject: Re: OO Challenge


"Weirich, James" <James.Weirich@FMR.COM> schrieb im Newsbeitrag
news:1C8557C418C561429998C1F8FBB283A728BA48@MSGDALCLB2WIN.DMN1.FMR.COM...
> I'll throw in my version.  Logically it is structured very much like
Robert
> Klemme's except that I made lighter weight choices for some of the
> abstractions.  For example, I use simple procs for the tax groups and my
> TaxPayer is Struct based.   What is really interesting is that despite
the
> differences in representation, the last bits of our programs are
identical
> except for minor spelling differences.

Probably there's not too much room for variations with this small example.
Or we think along the same lines.  Could be interesting to see with what
others come up.

Rereading the original posting I think the author of these lines has not
yet fully understand OO:

"Tax Payer problem is all about object (tax_payer) - class (soldier ...)
membership and polimorphic functions, just it is not that simple as
designers of OO languages believe (object is member of only one class (and
superclasses) and does not change its membership, function version can be
decided solely on class membership) - hence one is forced to handle
membership relation on his own, and OO support integrated in the language
is shown to be restrictive and cluttering."

In fact there are only few languages in which an instance can change its
class at runtime. I'm not sure about belonging to several classes at the
same time.  Even if there were, I'd be curios how that should be modelled
(after all you have to invoce *all* calculation methods before deciding on
the return value.)

But that doesn't necessarily mean that OO languages are not well suited
for this problem.  In fact, any of the ruby solutions looks cleaner to me
than the VB examples. My 2 cent...

> Here's the code.
[snip]

Great short implementation!  I always like to see how small programs can
get in Ruby.  Unfortunately that reminds me that I sometimes do seem to
make things unnecessary complicated...  *sigh*

OTOH we don't know what these groups are supposed to do other than
calculating the tax value.  They sure have some weird code that uniquely
identifies... :-)

> Disclaimer: I don't believe this example says anything deep or
> significant about OO verse non-OO.

Very much indeed so.  I still wonder why the OP did not put the original
link here - if there is any at all...

Regards

    robert