[ABE.pm] Seeking comments re OOP (Continuing my series of dumb questions)

[Randy Kramer]

Thanks again for the reply!

On Wed, 29 Dec 2004 17:07:09 -0500, Ricardo SIGNES
<rjbs-perl-abe at lists.manxome.org> wrote:
> Why?  It would just make things confusing.  You'd have to remember what
> was an object and what wasn't.  

Probably a good point.  (I only say probably, because at this point of
my Ruby learning, it seems intuitive that an object is an object, and
a member (method, attribute, whatever) of an object would not be an
object.)  (Clearly, confusion is not a good thiing!)

> This is only useful if you get a serious
> benefit from that cost.

Absolutely!

> Plenty of language and compiler designers have dealt with this issue
> before.  If thousands of people use Ruby and other highly OO languages,
> this should be a sign that your armchair speculation is wrong.
> Smalltalk and Eiffel gave us seriously OO languages in a day when the
> performance (and maturity of the implementations) kept them from winning
> the day.  Other languages had to go back to less-OO design to win out.
> Ruby has come again, giving us an OO system that is plenty fast enough.
> 
> Let's not argue about whether it's fast enough in theory when you
> haven't tried to see whether it's fast enough is practise.  

Ok! ;-)

> It IS
> premature optimization, whether you want to admit that or not.  I hope
> you don't think that it would just be easier for the programmer to not
> have numbers be objects.  It isn't.  If half of everything is an object,
> it's better to go all the way and keep things self-similar.

> Because BankBalance isa Number, the cmp method is implemented, and you
> can sort accounts by blanace.  

Just out of curiosity, I guess the syntax for that would be something like:

<bank account>.<bank balance>.sort

?
> This saves you from writing a way to sort
> balances.  Because BankBalance is an object, it can have additional
> attributes like "NativeUnit" so that balances in different monetary
> units can be compared with live exchange rates using the help of your
> MoneyMarket class.

That would be useful!

> 
> So what?  Who cares?  This is STILL a premature optimization discussion,
> whether it's at the algorithm level or at the language design level.

OK.

> Any sane and informed human will cede that you could write a program in
> C to do what any given Ruby program does.  Let's even be OO and say that
> you could use Obj-C to write a program that does what a Ruby program can
> do.  It will be faster, if you wrote it well.  Unless that speed
> difference matters, you will be writing thousands (probably tens or
> thousands, or more) of lines of code for no gain.

And I definitely don't want to do that!

Randy Kramer