From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 16249 invoked from network); 16 May 2020 10:21:35 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 16 May 2020 10:21:35 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 681789C5FC; Sat, 16 May 2020 20:21:30 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id C45C99C5EE; Sat, 16 May 2020 20:21:01 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="dfVRth7A"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 56ACF9C5E5; Sat, 16 May 2020 20:20:58 +1000 (AEST) Received: from mail-wm1-f67.google.com (mail-wm1-f67.google.com [209.85.128.67]) by minnie.tuhs.org (Postfix) with ESMTPS id 32D189C5E4 for ; Sat, 16 May 2020 20:20:57 +1000 (AEST) Received: by mail-wm1-f67.google.com with SMTP id d207so15641793wmd.0 for ; Sat, 16 May 2020 03:20:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=04wHHkZxzpWx6QXYpiJ9xdupx0QqNhwSPIyCaWzEIG0=; b=dfVRth7Auf2sFq96s0GgeSFh1HHDBeVymO/iXNXKIh3SqFx9nGz8vRl76b7Rq9+lGa zBsl45RuJRX8HKWL9SFvUYDWXzzrRYFvphPZbEVDb8I2w9bjB8GAmf366ERUvRr628DE hwuGyXBpBdNKR2Om8Hwc4+ze64Bo0HKUdsKnVY21CNvFqk0bXdP8mhBWHusEDI7RWnb/ et8z8TgvfKv6dDIQ235EF9k+iz5HVHGziTTS0BG9OruWhBfbU1u3SvW1gxYMZtDSlbre 9bjQ9CQr5+W2aCWBLz5gUOvjXu3fmOaUsbjvOPIrKs00A6PbTM9e+pOvUx3oWs3Xy023 0hdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=04wHHkZxzpWx6QXYpiJ9xdupx0QqNhwSPIyCaWzEIG0=; b=K6in+amuR5kaqRg9OJbVDn9P2Ba5bQF76iU33gh7IRvxriqCv5PgreNerv7Q66rn+1 L+x2b4uA0MSG2ms/M9Q/LSgHbaVFenT7fOL9V38nsUjuTfUJnBeoS4Nn2TGrVuf6wN4Y ni33/UJ+LaDj3wlS/VHcPLW0CeClM4mu1K+AxP3dHmIa1qu/OCzjIcaKOl1HYRV1WCql Ew6CvILKRpenR7b5A/b6ih3z3TS8CS8aTPtH8gQuJj8v/wXxiSP75r4EF/CBlHnFS0KR qbaErWEj+5Wk2ucQAHJ1Ri+Y7tf7+0E0g/1ask8Xq8kEKXy/0V+y8yjzBSyUR36Se3/D S2gQ== X-Gm-Message-State: AOAM531aT0WY0LAby1sjoIWU5OS/DWCPWUI3vC4/8kpSsQPqEEKYegR8 62pcQbd/0zHrVTAq/ImaFGDuuIisozY= X-Google-Smtp-Source: ABdhPJyhjX1HZyzlO2OFN3RuE9w3oWX0s86EZk1o3Elsit+gliDPUwTJfPpxwfViIMkWh2qairWWdg== X-Received: by 2002:a1c:e157:: with SMTP id y84mr8534929wmg.15.1589624455326; Sat, 16 May 2020 03:20:55 -0700 (PDT) Received: from [192.168.0.53] (e153060.upc-e.chello.nl. [213.93.153.60]) by smtp.gmail.com with ESMTPSA id 60sm7688191wrp.92.2020.05.16.03.20.53 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 16 May 2020 03:20:54 -0700 (PDT) From: Don Hopkins X-Google-Original-From: Don Hopkins Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_DB070406-1327-4A21-ABAA-204DCE04F897" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Sat, 16 May 2020 12:20:52 +0200 In-Reply-To: To: TUHS main list References: X-Mailer: Apple Mail (2.3608.80.23.2.2) Subject: [TUHS] A la carte menu of OO features or properties X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Don Hopkins Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --Apple-Mail=_DB070406-1327-4A21-ABAA-204DCE04F897 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The properties of object oriented programming are better described as an = la carte menu like a cafeteria buffet or sm=C3=B6rg=C3=A5sbord, than a = point, line, or continuum.=20 http://www.paulgraham.com/reesoo.html = Paul Graham: Reese Re: OO (Jonathan Rees had a really interesting response to Why Arc isn't = Especially Object-Oriented, which he has allowed me to reproduce here.) Here is an a la carte menu of features or properties that are related to = these terms; I have heard OO defined to be many different subsets of = this list. =E2=80=A2 Encapsulation - the ability to syntactically hide the = implementation of a type. E.g. in C or Pascal you always know whether = something is a struct or an array, but in CLU and Java you can hide the = difference. =E2=80=A2 Protection - the inability of the client of a type to = detect its implementation. This guarantees that a behavior-preserving = change to an implementation will not break its clients, and also makes = sure that things like passwords don't leak out. =E2=80=A2 Ad hoc polymorphism - functions and data structures = with parameters that can take on values of many different types. =E2=80=A2 Parametric polymorphism - functions and data = structures that parameterize over arbitrary values (e.g. list of = anything). ML and Lisp both have this. Java doesn't quite because of its = non-Object types. =E2=80=A2 Everything is an object - all values are objects. True = in Smalltalk (?) but not in Java (because of int and friends). =E2=80=A2 All you can do is send a message (AYCDISAM) =3D Actors = model - there is no direct manipulation of objects, only communication = with (or invocation of) them. The presence of fields in Java violates = this. =E2=80=A2 Specification inheritance =3D subtyping - there are = distinct types known to the language with the property that a value of = one type is as good as a value of another for the purposes of type = correctness. (E.g. Java interface inheritance.) =E2=80=A2 Implementation inheritance/reuse - having written one = pile of code, a similar pile (e.g. a superset) can be generated in a = controlled manner, i.e. the code doesn't have to be copied and edited. A = limited and peculiar kind of abstraction. (E.g. Java class inheritance.) =E2=80=A2 Sum-of-product-of-function pattern - objects are (in = effect) restricted to be functions that take as first argument a = distinguished method key argument that is drawn from a finite set of = simple names. [=E2=80=A6] (See the web page and the original thread for a discussion of which = languages implement which of the above features.) http://www.paulgraham.com/reesoo.html = = https://web.archive.org/web/20160308032317/http://www.eros-os.org/pipermai= l/e-lang/2001-October/005852.html = -Don --Apple-Mail=_DB070406-1327-4A21-ABAA-204DCE04F897 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
The properties of object oriented programming are better = described as an la carte menu like a cafeteria buffet or sm=C3=B6rg=C3=A5s= bord, than a point, line, or continuum. 

http://www.paulgraham.com/reesoo.html

Paul Graham: Reese Re: OO

(Jonathan Rees had a really interesting response to Why = Arc isn't Especially Object-Oriented, which he has allowed me to = reproduce here.)

Here is an a la carte menu = of features or properties that are related to these terms; I have heard = OO defined to be many different subsets of this list.

=E2=80=A2 Encapsulation - the = ability to syntactically hide the implementation of a type. E.g. in C or = Pascal you always know whether something is a struct or an array, = but in CLU and Java you can hide the difference.

=E2=80=A2 Protection - the = inability of the client of a type to detect its implementation. This = guarantees that a behavior-preserving change to an = implementation will not break its clients, and also makes sure that = things like passwords don't leak out.

=E2=80=A2 Ad hoc polymorphism - = functions and data structures with parameters that can take on values of = many different types.

= =E2=80=A2 Parametric polymorphism - functions and data structures = that parameterize over arbitrary values (e.g. list of anything). ML and = Lisp both have this. Java doesn't quite because of its non-Object = types.

=E2=80=A2 = Everything is an object - all values are objects. True in Smalltalk (?) = but not in Java (because of int and friends).

=E2=80=A2 All you can do is send = a message (AYCDISAM) =3D Actors model - there is no direct manipulation = of objects, only communication with (or invocation of) them. The = presence of fields in Java violates this.

=E2=80=A2 Specification = inheritance =3D subtyping - there are distinct types known to the = language with the property that a value of one type is as good as a = value of another for the purposes of type correctness. (E.g. Java = interface inheritance.)

= =E2=80=A2 Implementation inheritance/reuse - having written one = pile of code, a similar pile (e.g. a superset) can be generated in a = controlled manner, i.e. the code doesn't have to be copied and = edited. A limited and peculiar kind of abstraction. (E.g. Java class = inheritance.)

=E2=80=A2 = Sum-of-product-of-function pattern - objects are (in effect) restricted = to be functions that take as first argument a distinguished method = key argument that is drawn from a finite set of simple = names.

[=E2=80=A6]

(See the web page and the original thread for a discussion of = which languages implement which of the above features.)

http://www.paulgraham.com/reesoo.html

https://web.archive.org/web/20160308032317/http://www.eros-os.o= rg/pipermail/e-lang/2001-October/005852.html

-Don

= --Apple-Mail=_DB070406-1327-4A21-ABAA-204DCE04F897--