|
Scott Meyers wrote an interesting C++ article:
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
| 
