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.
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…
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.
Here’s the code.
def tax
tax_classes.collect { |tc| tc.call(self) }.max
end
I like James’ solution best because he has tax_classes 'collect’ing - which
seems to model the real world well :).
def tax(earning, tax_groups)
tax_groups.collect { |g| g.call(earning) }.max
end
puts tax(3000, [TaxSoldier, TaxProfessor])
Pretty much a line for line translation. Why so much shorter than
previous versions? Because we threw out the tax payer abstraction and
just pass around earning (e.g. salary).
···
On Fri, 2003-09-12 at 10:57, Weirich, James wrote:
The article was about Eiffel.
But the guy blasted OO …
I know from experience that the least you know - the more you think you
know
So obviously that guy was whizzing on an ego trip.
He fails to realize that OO is to encapsulate and reduce complexity for
larger programs - not trivial examples.
His example is silly.
As OO is usually built on procedural-like code.
Now … if he were to have an example involving a more complex application
Then he would lose ground - he is cheating, setting the rules - with an example of
20 lines or so.
As I stated I tried VB.NET because you can do illegal things
that makes code more sugary-like.
With C# you can make classes morph into others - while introducing some
ugly parameters. (Perhaps) the solution could have been more concise.
But I was aiming for the solution to be readable when declaring.
That is IMO … what OO is for. Work hard to make it easier.
I was close to finding a solution - but no EVAL in VB, and didn’t want to
thread at MSDN for hours, … I got sick of Visual Studio .NET slow,
crawling once more -hanging on “Wait 20 minutes …” (P-OFF MS! grrrr).
Refreshing to be here under Linux again
Thanks again.
I will look into RUBY more
I am looking for a nice language.
I tried Smalltalk but couldnt get round it. I feel even embarrased about
it
Ruby seems to be more my style!
I deffy want to re-write a site which I began with C#.
So any advice on RUBY (ie links) for rendering pages and dealing with Response Fields
is much appreciated.
Of course I will always be searching through posts here trying to learn as much as
poss.
He fails to realize that OO is to encapsulate and reduce complexity for
larger programs - not trivial examples.
I think the posted examples show that even simple programs can benefit
from OO (and especially Ruby) - at least by increased readability but also
by reduced code (you get polymorphism and a lot of other stuff for free).
I deffy want to re-write a site which I began with C#.
So any advice on RUBY (ie links) for rendering pages and dealing with
Response Fields
is much appreciated.
Look out for eruby, amrita, apache mod-ruby and the like.
Of course I will always be searching through posts here trying to learn
as much as
poss.
