[Prev][Next][Index][Thread]

How Non-Member Functions Improve Encapsulation

Another member kindly pointed me to this message from last year:

-------- Original Message --------
Subject: How Non-Member Functions Improve Encapsulation
Date: Wed, 23 Aug 2000 10:32:08 -0700
From: Chris Page <page@best.NOSPAM.com>
Organization: SBC Internet Services
Newsgroups: comp.lang.dylan

Scott Meyers wrote an interesting C++ article:

  "How Non-Member Functions Improve Encapsulation"

  <http://www.cuj.com/archive/1802/feature.html>

Which I read as an argument for Dylan's style of object model, where:

- classes (ideally) only declare slot getter and setter functions

- other related functions are written in terms of slot getters/setters

- class names and related function names are placed in a common namespace
  to indicate their relatedness

He points out that encapsulation is increased because only the getters and
setters need to be rewritten if the slot implementations change, and this
type of change does not alter the "interface" of a class. Furthermore,
subsets of the interface can be placed in separate headers, minimizing
compilation dependencies and allowing for recombining them into
application-specific interfaces.

It felt like I was reading about Dylan modules.

It also made me smile when he acknowledged that the syntax for calling
non-member functions "member(foo)" is different from accessing members
directly "foo.member", because Dylan (in its all-knowing benevolent wisdom
:-) allows for the same syntax to be used for both, confirming their
semantic equivalence.

I'm glad to report that he says it is a trivial difference. He points out
that there are generally a number of non-member functions that operate on
classes: "If you reflect a bit and are honest with yourself, you1ll admit
that you have this alleged inconsistency with all the nontrivial classes you
use, because no class has every function desired by every client. Every
client adds at least a few convenience functions of their own, and these
functions are always non-members."

Sounds like an argument for generic functions.

This further bolsters my view that Dylan's programming style can and should
be applied to C++ (and probably other languages). Which is to say, there's a
great deal to be learned from Dylan about programming in general that can be
applied other languages. Of course, this just makes me miss programming in a
language that directly supports this style.

-- 
Chris Page
Mac OS Guy
Palm, Inc.

let mail-to = concatenate( "Chris Page <page", "@", "best.com>");


Scott Ribe
scott_ribe@killerbytes.com
http://www.killerbytes.com/
(303) 665-7007 voice

------------------ RFC822 Header Follows ------------------
From: Scott Ribe <scott_ribe@killerbytes.com>
To: <info-dylan@ai.mit.edu>, <doug@postsmart.net>, <>
Subject: How Non-Member Functions Improve Encapsulation
Date: Fri, 26 Jan 2001 19:06:28 -0700
Message-Id: <19341221193812.28023@smtp.rmi.net>
X-Mailer: CTM PowerMail 3.0.6 <http://www.ctmdev.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
-----------------------------------------------------------