Re: Interesting take on Paradigms (OO vs Procedural)

"Rick Smith" <ricksmith@[EMAIL PROTECTED]
> wrote in message 
news:13utjs3674qjr8f@[EMAIL PROTECTED]
>
> "Pete Dashwood" <dashwood@[EMAIL PROTECTED]
> wrote in message
> news:657mp4F2dooroU1@[EMAIL PROTECTED]
>>
>>
>> "Rick Smith" <ricksmith@[EMAIL PROTECTED]
> wrote in message
>> news:13ur5tg3con5ja4@[EMAIL PROTECTED]
>> >
>> > "Pete Dashwood" <dashwood@[EMAIL PROTECTED]
> wrote in message
>> > news:65553nF2cjsrhU1@[EMAIL PROTECTED]
>> >>
>> >>
>> >> "Rick Smith" <ricksmith@[EMAIL PROTECTED]
> wrote in message
>> >> news:13uq9i0e2sfdd1a@[EMAIL PROTECTED]
>> >> >
>> >> > < http://www.cs.berkeley.edu/~jrs/4/lec/14
>
>> >> > -----
>> >> > Why did the originators of object orientation rename "structures"
to
>> >> > "objects"
>> >> > and "procedures" to "methods"?  Hubris and arrogance, in my
opinion.
>> >>
>> >> This simply says that the writer has not really understood the
> essential
>> >> differences. I read the full article and he/she does a good job of
>> >> listing
>> >> the differences, but identifying differences and actually 
>> >> understanding
>> > the
>> >> implications of those differences are two different things.
>> >>
>> >> The comment above implies that the commentator sees no difference
> between
>> > a
>> >> "structure" and an "object", yet anyone who has worked with these
> things
>> > in
>> >> the real world would understand the essential difference. This is
the
>> >> difference between Acadaemia and Reality.
>> >
>> > H'm! Structure, in procedural, is accessed through a pointer.
>> > Object, in object-based, is accessed through a reference.
>> > Object, in object-oriented, is accessed through a reference;
>> > but also holds a "vtable" to accommodate inheritance and
>> > polymorphism.
>> >
>> > The essential difference seems to be the extension of the
>> > structure to add the "vtable" making the object a bigger
>> > structure.
>> >
>> You are looking only at the mechanics of an implementation. The 
>> conceptual
>> use of objects is WAY more im****tant. But you only come to appreciate 
>> that
>> when you start using them for systems in the real world, and not just
to
>> describe some academic argument.
>>
>> Whether objects implement inheritance through a vtable or not is
> completely
>> irrelevant to the use of objects. For you, an object is just a
structure
> in
>> memory; for me, it is much more than that. I visualise objects as
>> representing a real world entity and having attributes and behaviours 
>> that
> a
>> structure alone can never have. Perhaps it comes down to imagination
and
>> vision.
>
> I used to see objects as real world entities. Now I associate
> real world entites with cl*****, because the methods in the
> cl***** repesent behavior.

Yes, that is fair comment. I used "object" (an instance of a Class) where
I 
should probably have used "Class".

Certainly the Class has methods which constitute the behaviour of the
Class 
but until it is instantiated there is no behaviour anyway, so perhaps 
"object" is not really so wrong.

> If one is to "simulate" anything,
> it is the behavior that is to be simulated.

Technically that is true. The data isn't simulated. But conceptually it is

the synergy derived from the COMBINATION of behaviours AND data (as a
single 
encapsulated whole) that makes Objects so powerful.
>
> To simulate a business, the behavior occurs in employees,
> customers, orders, accounts, etc.; but to simulate the
> financial systems of a business the behavior is in clerks, and
> the employees, customers, orders, accounts, etc., become
> just data structures devoid of behavior.

Only if you see it like that. :-)

At this point, I think we diverge.

> This is not much
> different than a card game, where the dealer and players
> have behavior but the cards don't; even though the cards
> are real world entities.

The cards certainly DO exhibit behaviour. If they behave well you go home 
rich. :-)

Pete.
-- 
"I used to write COBOL...now I can do anything."