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

[Randy Kramer]

Ricardo,

Thanks for the response!  I've added some comments / thinking out loud below.

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

Is that assumption correct?

Aside: I'm not sure how much overhead is associated with an object
(I'll probably learn more when I re-read chapter 24):
   * it may be so little as to be meaningless in most cases (ignoring
garbage collection when the balance changes)
   * even the overhead of garbage collection may be meaningless in most cases
   * I don't want to get into a discussion about premature
optimization--right now I see Ruby (or some similar language) my
ticket to create a (fairly complex) application fairly quickly--if I
find it too slow (for any definition of too slow) I'll then consider
optimizing, either within Ruby, rewriting parts in C and continuing to
use Ruby, or rewriting in something else period.

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

Hmm, I might have said everything I wanted to say here without
responding to particular points in your reply.  Let me check that...
Well, I have some comments down there, read them at your own risk. ;-)

Randy Kramer

On Tue, 28 Dec 2004 17:52:41 -0500, Ricardo SIGNES
<rjbs-perl-abe at lists.manxome.org> wrote:
> * Randy Kramer <rhkramer at gmail.com> [2004-12-28T14:16:21]
> > It seems that in Ruby and Python, those numbers (all numbers) are
> > objects, but, at least in the context of a banking application, I
> > don't see the value of having those numbers be objects vs. simply
> > being "values" without representing objects.  Instead, it seems like
> > having those numerical values be objects rather than values (not
> > objects) just adds some extra overhead.
> >
> > Of course, if your programming in a language that treats all numbers
>>>>>>>>>>>>^you're (grammo/typo fix)
> > as objects, that's what you live with, it just seems like overkill or
> > something.
> >
> > Comments?
> 
> If fixed numbers are objects, they gain methods.  If they have methods,
> they have a morphology that other objects can emulate, and they begin a
> class hierarchy from which other classes can descend.
> 
> 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.

> Which helps reinforce the rest of Ruby's loop types -- that it, methods
> on objects that define the loop.  Or, conversely, because everything
> /else/ is an object, like a Range, the programmer gets used to having
> methods on objects for doing useful things like loop and get related
> values.
> 
>         Range.each { |x| puts x }
>         Range.max

Ok, the point about a programmer getting used to having methods ... is useful.

> 
> So, by making every type an object, this metaphor works everywhere.  It
> makes things more homogenous.  In fact, this is one of the places where
> Ruby trumps Python.  Python acts as if all values are objects and have
> methods, but a number of methods don't exist in "public" space.  To
> delete a list element, for example, you must use the delete function, or
> some private method like __delete__.
> 
> You said this seems like overkill.  I don't understand that criticism.
> Does it slow your program down in some way that you can measure or
> prove?  Does it result in having to write more code?  (Presumably it
> actually means you need to write less.)

Writing less code will be nice.  I can't judge that at this time (no
code written ;-).  As far as slowing down my program in a way that I
can measure or prove, I don't intend to take the time to measure or
prove it (after I write some code ;-).   As stated above, after I
write my application, I'll see if it is too slow / too bloated and
then consider ways to address the problem.

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

Randy Kramer