Re: Interesting take on Paradigms (OO vs Procedural)

"Rick Smith" <ricksmith@[EMAIL PROTECTED]
> wrote in message 
news:Z4CdncSCCf-RM2LanZ2dnUVZ_hisnZ2d@[EMAIL PROTECTED]
>
> "Pete Dashwood" <dashwood@[EMAIL PROTECTED]
> wrote in message
> news:6688cfF2ii6kvU1@[EMAIL PROTECTED]
>>
>>
>> "Joe Zitzelberger" <zberger@[EMAIL PROTECTED]
> wrote in message
>> news:zberger-A7F0BE.00153011042008@[EMAIL PROTECTED]
> [snip]
>> > You can certainly use OO compilers to write procedural type code as
you
>> > describe -- or you can use procedural only compilers to write OO
style
>> > code as long as you enforce your the OO rules yourself.
>>
>> Absolutely. The fact is that when you encapsulate behaviours and
> properties
>> into an Object, the synergistic whole, is far greater than the sum of
its
>> parts. The code representation is only ONE aspect of it.
>
> Pete, sometimes you make it too difficult for me
> to not care! <g>

How you feel about things is entirely a matter for you, just as how I feel

about things is up to me.

Generally, you make it VERY easy for me to stop caring...:-)

>
> The fact is that were one to encapsulate behaviors and
> properties into (a COBOL 68 program as) an object, it
> would not be more than what it appears to be.

I make a simple statement, intended to express a concept. (There is a 
synergy obtained when you create objects. Part of that synergy is the fact

that you can use objects in many ways OUTSIDE of expressing them as
computer 
code.)

"The fact is that when you encapsulate behaviours and properties into an 
Object, the synergistic whole, is far greater than the sum of its
 parts. The code representation is only ONE aspect of it."

But ALL you see is the code representation. (So what about your OOA and
OOD? 
Is OOP ALL you can actually see? Yes, of course, your Object Oriented 
Analysis is designed to derive objects to be coded and your Object
Oriented 
Design is intended to optimise them in code, so your OOP can manipulate
them 
in code. That is the full extent of your interest.)

"Oh no, Pete. If I do that with COBOL 68 I don't have any synergy..."

Well, Gee, Rick... might be time you moved off COBOL 68.

(See how easy it is for me to stop caring about the whole discussion when
I 
am dealing with someone who relates what I say to a compiler from 40 years

ago, that never sup****ted OO anyway? It's just silly.)

And you're wrong anyway. Whether or not it was "more than what it appears
to 
be" depends on how imaginatively you use it.

If the various methods were written as entry points, they could be
activated 
independently of each other but sharing "factory" data, so the module 
already has a capability that it wouldn't have were it written as a series

of modules to implement each method in the usual COBOL way.

>Add
> inheritance and polymorphism and the picture changes
> dramatically. The ability to substitute (an object of) one
> subclass with (an object of) another subclass (both
> derived from the same class), with no change to the
> underlying code, is what I see as synergistic.

Yes, but how dry is that.

>
> [I think the above also helps demonstrate why "object"
> should not be used. It is difficult to define a proper
> relation****p between objects without reference to "class".]
>

I don't find myself discussing relation****ps between objects of a class
very 
often in these discussions, so "object" serves perfectly well as a general

description of what I'm talking about. Should the need arise to discuss 
specific objects, and confusion is possible I would simply use dot
notation: 
Class.Object.

But I don't expect to be discussing this further anyway, so it is moot.

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