projecktzero wrote:
> A co-worker considers himself "old school" in that he hasn't seen the
> light of OOP ... He thinks that OOP has more overhead and is slower
> than programs written the procedural way.
He may be right, but consider the alternatives.
Think of an integer. An integer is an object!
You can assign a new integer-value to the object.
You can read the integer-value of the object.
(The integer can be part of complex expressions.)
Usually you are unaware (or don't care) _how_ the object is implemented.
Wether the bits are red, green, turns upside-down or are inverted - you
doesn't really care, as long as it can hold the values that you want it to
hold and be used in the relevant contexts (addition, multiplication, ...).
Some lanugages gives you the choise of many integer-implementations, some
languages gives you only a few choises and some languages gives you only one
choise.
Surely we can agree that the presence of an integer-object is extremely
useful! If you had to do all the integer-stuff in machine code _every_ time,
you would soon be very, very tired of working with integers. There is no
doubt that objects are (or can be) extremely useful, time-saving and very
efficient. Chances are that your own machine-code integer-inplementation is
not nearly as good as the one made by a team of top-tuned programmers (no
offense) programming the integer-implementation "object".
Wether the language should give you the choise of one, some, many or
extremely many integer-implementations, depends entirely on your needs
("what a pervert - he needs an integer!"). Lowering the number of choises of
implementations, rises the chances of having to chose a "not very good"
implementation. Letting the language automaticly chose the right one, frees
your mind to other processes, but at the risk of some kind of run-time
overhead.
-------
Tomas
--
http://mail.python.org/mailman/listinfo/python-list
