--TuDq1L/8sppbj67qmiZ
Content-Type: multipart/alternative; boundary="=-pF2dUYqRn6BX/xSWDhbf"


--F2dUYqRn6BX/xSWDhbf
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Thu, 2008-05-29 at 07:23 +0900, Mark Wilden wrote:

> One of the purposes of classes in OOP is to categorize things.


One of the weaknesses of classic Booch, et al OOP is that one of the
purposes of classes in OOP is to categorize things.

Classes in classic OOP languages conflate a variety of concepts and cram
them into one structure which does none of them particularly well:

     1. Classes are the unit of state.
     2. Classes are the unit of access control.
     3. Classes are the unit of functional dispatch.

In extreme cases (Java, I'm looking at you here!) classes are also the
unit of packaging.  (In other classic OOP language cases the unit of
packaging is an ad-hoc mess.  C++ I'm looking at you here!)

I personally have always preferred the Dylan model (which I understand
comes from the CLOS model, watered-down somewhat):

     1. Classes are the unit of state.
     2. Modules (and, to a point, libraries) are the unit of access
        control.
     3. Generic functions are the unit of functional dispatch.
        (Multi-methods!  Yay!)

And, unlike Java or C++, libraries are the unit of packaging.

I found that neatly layered structure of orthogonal concerns modelled by
separate mechanisms a breath of fresh air after coming from the bizarre
world of class OOP.

-- 
Michael T. Richter <ttmrichter / gmail.com> (GoogleTalk:
ttmrichter / gmail.com)
When debugging, novices insert corrective code; experts remove defective
code. (Richard Pattis)

--F2dUYqRn6BX/xSWDhbf
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/3.16.1">
</HEAD>
<BODY>
On Thu, 2008-05-29 at 07:23 +0900, Mark Wilden wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">One of the purposes of classes in OOP is to categorize things.</FONT>
</PRE>
</BLOCKQUOTE>
<BR>
One of the weaknesses of classic Booch, et al OOP is that <B>one</B> of theurposes of classes in OOP is to categorize things.<BR>
<BR>
Classes in classic OOP languages conflate a variety of concepts and cram them into one structure which does none of them particularly well:
<OL TYPE=1>
    <LI TYPE=1 VALUE=1>Classes are the unit of state.
    <LI TYPE=1 VALUE=2>Classes are the unit of access control.
    <LI TYPE=1 VALUE=3>Classes are the unit of functional dispatch.
</OL>
In extreme cases (Java, I'm looking at you here!) classes are also the unitf packaging.&nbsp; (In other classic OOP language cases the unit of packaging is an ad-hoc mess.&nbsp; C++ I'm looking at you here!)<BR>
<BR>
I personally have always preferred the Dylan model (which I understand comes from the CLOS model, watered-down somewhat):
<OL TYPE=1>
    <LI TYPE=1 VALUE=1>Classes are the unit of state.
    <LI TYPE=1 VALUE=2>Modules (and, to a point, libraries) are the unit of access control.
    <LI TYPE=1 VALUE=3>Generic functions are the unit of functional dispatch.&nbsp; (Multi-methods!&nbsp; Yay!)
</OL>
And, unlike Java or C++, libraries are the unit of packaging.<BR>
<BR>
I found that neatly layered structure of orthogonal concerns modelled by separate mechanisms a breath of fresh air after coming from the bizarre worldf class OOP.<BR>
<BR>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
-- <BR>
<B>Michael T. Richter</B> &lt;ttmrichter / gmail.com&gt; (<B>GoogleTalk:</B> ttmrichter / gmail.com)<BR>
<I>When debugging, novices insert corrective code; experts remove defectiveode. (Richard Pattis)</I>
</TD>
</TR>
</TABLE>
</BODY>
</HTML>

--F2dUYqRn6BX/xSWDhbf--

--TuDq1L/8sppbj67qmiZ
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBIPonFLqyWkKVQ54QRAg7BAKDY41M3CWftXUceL4CpAdHbZZJ1LwCfTi3u
OEr+SSxCNLei0KXqD7p/oyoTv
-----END PGP SIGNATURE-----

--TuDq1L/8sppbj67qmiZ--