[Prev][Next][Index][Thread]
How Non-Member Functions Improve Encapsulation
-
To: info-dylan@ai.mit.edu
-
Subject: How Non-Member Functions Improve Encapsulation
-
From: Chris Page <page@best.NOSPAM.com>
-
Date: Wed, 23 Aug 2000 13:45:01 -0400 (EDT)
-
Organization: SBC Internet Services
-
User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022
-
Xref: traf.lcs.mit.edu comp.lang.dylan:12661
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, youšll 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>");
Follow-Ups: