Re: Meyer(s) gets it wrong

From: Ian Woods (newspub2_at_wuggyNOCAPS.org)
Date: 02/19/04 

Date: Thu, 19 Feb 2004 02:13:03 +0000 (UTC)

Programmer Dude <Chris@Sonnack.com> wrote in news:4033937B.E0860628
@Sonnack.com:

> "Michael N. Christoff" wrote:
>
>> I've always understood OOA/D as the process of developing systems
>> in which computation is achieved through the collaboration of
>> autonomous processes with encasulated internal state.
>
> That's a good technique, which I think predates OOP. Programmers
> encapsulated state and developed autonomous "objects" before OOP.
>
> I've taken (and this may be particular to me) OO[ADP] to also
> define a coding technique that uses things like "classes" as a
> native language construct, inheritance and object polymorphism.
>
> What prevents me, I think, from seeing network computing as "OOP"
> is the (to my eye) lack of inheritance and polymorphism. Clearly
> the encapsulation aspect is present, though!

Surprisingly, polymorphism and inheritence are rather trivial to show...
but not in the same way that many, supposed, OO languages support them.
Part of this is odd, and ask that "what actually /is/ *" kinds of
questions.

An objects interface defines a license - no more, and no less. It's a
license for the kinds of data an object will accept and the kinds of data
an object will produce. In 'active object', 'asynchronous object' land,
that means the data accepted or produced could (potentially) be at any
time. In most OO circles, the data produced is merely in reponse to some
data accepted.

So, polymorphism:

I have two programs running on (optionally) seperate computers. Both
programs use the same protocol (i.e. interface) but do different
operations. The protocol is published and available.

So, inheritence:

I have two programs running on (optionally) seperate computers. Program A
uses some protocol. Program B uses an optionally a restricted or expanded
protocol compatible with that from program A.

TBH I find the idea of seperate processes which have defined interfaces,
and optionally relationships between their interfaces, to be more 'in the
spirit' of OO than the capabilities of most so-called OO languages.

>> Anyways, I think saying that OOP (most prominently the class\object
>> concept, encapsulation and interfaces) is well suited to
>> implementing distributed systems is different from saying OOA/D =
>> distributed computing. However, I must admit, I find the
>> similarities both stricking and numerous.
>
> I agree! And there may come a time--if distributed computer really
> takes off--when creating such "objects" WILL be very much like
> creating objects in an OOPL.

I do, in fact, have a language with such properties already defined...
noting of course that even current OO languages have (some) support for
remote access of objects using things like SOAP. The one thing they
appear to lack is the idea of these 'objects' being asynchronous.
 
>>>>> 'Swhat I've been saying for years!
>>>
>>> [..Sir SnipAlot was here...]
>>>
>>> (Why ask me?! Not my website!! :-)
>>
>> Sorry. I thought you implied you agreed with what this guy was
>> saying.
>
> Just that bit I first quoted about OOP being just an organizational
> technique. (Got into a longish debate here a while back when I
> wrote that I saw Procedural Programming as "verb oriented" and OOP
> as "noun oriented". Despite that, I still do think of it that way.
> The words are the same (i.e. you write the same code), but they are
> organized differently.)

To anyone sufficiently skilled in the art of programming, it's clear that
OO is 'merely' a reorganisation. Widespread OO languages take what is
good about structured programming wholesale, even though the benefits of
SP and OO are (at least in my eyes) orthogonal. OO, (IMO) defines many
aspects of the interface(s) of an 'entity' (thing holding datat) without
specifying anything about how the functionallity of the entity is
actually performed (which is where the SP comes in to play). In practice,
what's good in OO is /also/ good in SP... and in many cases could easilly
be described as being 'just' good SP practice. To me, then, OO (at least
while it's still synchronous) is merely a reorganisation of SP which has
'promoted' aspects of good SP practice which are /not/ explicitely coded
into SP. Similarly, SP is 'merely' a reorganisation of earlier 'good'
programming practices.

If anyone has any ideas of what happens at the end of all this 'good
practice'... I'd like to hear your thoughts on language design. :)

Ian Woods 

-- 
"I'm a paranoid schizophrenic sado-masochist.
My other half's out to get me and I can't wait."
Richard Heathfield

Relevant Pages

  • Re: Why encapsulate state pattern......
    ... >>>multiple interfaces. ... > state pattern. ... Some languages ... > IClosedPort closedPort = new CClosedPort; ...
    (comp.object)
  • Re: OS X.4.X update...
    ... back" some languages you have removed, unless they are smart enough not ... has very little in the way of multiple language support. ... applications which support Unicode - AppleWorks is not one of them). ... It doesn't even touch on the other things you can do with computers now ...
    (comp.sys.mac.system)
  • Re: Entity and Identity
    ...   I don't consider "OO" to be defined by the current ... suite of mainstream languages out there. ... I have no problem with state machines. ... I don't understand in what way implementing and using interfaces can ...
    (comp.databases.theory)
  • Re: Normal areas between two values: a home-made program
    ... Because the algorithm was do to span values greater than 0, the different signals of interval bounds were took into consideration. ... of computer hardware including process control computers. ... I've written code in other languages including C and C++. ... interpreter ...
    (sci.stat.math)
  • Re: SQL
    ... SQL is a specific language with certain ... relational nor query languages. ... which don't fully implement ADT. ... interfaces to such are often not as flexible as query-based interfaces. ...
    (comp.object)