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

[Ricardo SIGNES]

* Randy Kramer <rhkramer at gmail.com> [2004-12-29T12:19:40]
> Oops, before I comment further maybe I better check one of my
> assumptions (or rather, state it for you to correct. ;-)  I've assumed
> that all numbers are objects, e.g., something like a bank balance
> (that is part of another object) is also an object rather than just a
> "value" (a number in a register, but without the pointer structure and
> other stuff associated with an object).  (That stuff is described in
> chapter 24 of the Pickaxe (II) book and includes things like a pointer
> back to its superclass, etc.)

Language-Agnostic Response:
Sure, presumably you could handle a bank balance in one of two ways.
You've have an Account object, with a "balance" attribute, and that
attribute would either be a Number, which would be a very simple and
generic represenation of the number of dollars in the account, or a
Balance object that can act like a Number and has other methods and
attributes.

> I guess where I'm coming from (partly) is that it seems that rather
> than an "everything is an object" paradigm (is that part of Ruby's
> paradigm?), an everything *can be* an object paradigm could be more
> useful.  (And might be the basis for Ruby's successor someday.)

Why?  It would just make things confusing.  You'd have to remember what
was an object and what wasn't.  This is only useful if you get a serious
benefit from that cost.

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

> > Given fixed number 2, I can do things like:
> > 
> >         2.times { shake_it }
> 
> Ok, but I'm not sure I see a use for that when I'm talking about the
> balance in a bank account.  I don't expect to calculate a new balance
> due to interest (for example) by running a calculation <balance>
> times.

Because BankBalance isa Number, the cmp method is implemented, and you
can sort accounts by blanace.  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.

> At the risk of starting a controversy that I'll quickly bow out of, I
> think it's fairly well accepted that a compiled program is faster than
> an interpreted program (ignoring some things like the advantages of
> dynamic typing that appear to be (or so far have been) available only
> to interpreted languages (AFAIK).  My guess is that interpreted
> languages that treat everything as an object are (or can be) slower
> than an interpreted language that doesn't require that everything be
> an object.  (Again, if my assumption that the bank balance as part of
> a bank account object is also an object is wrong, then my comments
> here are (or should be) moot (or mute -- I'll have to look that up to
> see which is the more correct usage).

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

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.

-- 
rjbs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.pm.org/pipermail/abe-pm/attachments/20041229/4fecd2b4/attachment.bin