RE: What's so cool about Scheme?

["Bayley, Alistair" <address@hidden>]

> it's possible to do OO programming in almost any language

Sure. It just that OO languages provide explicit support for OO programming.
Within reason, you can more-or-less program in any style you choose in any
language you choose. It's obvious that for many styles, if you don't choose
a language that explicitly supports that style, then it is probably going to
be painful.


> >"Objects are encapsulated state machines exchanging messages amongst 
> >themselves, and with a number of external 'worlds'."

> ... Surely 'exchanging messages' is equivaled to 'functions calling each
other' ...

Imagine an ADT (say, in ML or Haskell). You can only use the provided
functions to create and manipulate values of this type. Is this an
encapsulated state machine that responds to messages? It looks very similar
to me. Is this object-oriented? Maybe, but that depends on your definition
of object-oriented.

Would it be fair to call it object-oriented if it was implemented in
Haskell, which is not generally recognised as an objected-oriented language?
Note that Haskell provides good support for defining opaque ADTs, so arguing
that "you've rolled your own" doesn't hold water, as you're not doing
anything the language doesn't support or encourage.


-----Original Message-----
From: Mike Newhall [mailto:mike@newhall.net]
Sent: 04 June 2003 06:50
To: Andrae Muys; ll1-discuss@ai.mit.edu
Subject: Re: What's so cool about Scheme?


At 01:20 PM 2003.06.04 +1000, Andrae Muys wrote:
>Matt Hellige wrote:
>Then I would be interested in understanding how this is different from the
>emphasis given to cohesion and coupling in structured programming.  If 
>OO dosn't mean anything more than encapsulation then I suggest the term 
>is meaningless, as an object becomes indistinguishable from an ADT.

	As has been said by many, it's possible to do OO programming in
almost any language, if you roll your own object implementation (and are
willing to rely on good programmer behavior instead of compiler enforced
rules where the limitations of the language require it).  Because the
paradigm existed before doesn't invalidate the term.

>My understanding of the term object is rather informal but roughly 
>equates to:
>
>"Objects are encapsulated state machines exchanging messages amongst 
>themselves, and with a number of external 'worlds'."

	That may be entirely true but what prevents that definition from
being semantically equivalent to saying "objects are data structures with
invariants enforced against external corruption via implementation functions
with priviledged access"?  Or any number of other choices of words; I think
it's a case of six of one, half a dozen of the other.  Surely 'exchanging
messages' is equivaled to 'functions calling each other', and all programs,
libraries, and functions deal with some external 'world'.


*****************************************************************
The information in this email and in any attachments is 
confidential and intended solely for the attention and use 
of the named addressee(s). This information may be 
subject to legal professional or other privilege or may 
otherwise be protected by work product immunity or other 
legal rules.  It must not be disclosed to any person without 
our authority.

If you are not the intended recipient, or a person 
responsible for delivering it to the intended recipient, you 
are not authorised to and must not disclose, copy, 
distribute, or retain this message or any part of it.
*****************************************************************