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

Re: Newbie question: Dylan and OOP?

in article 200101261924.OAA28394@life.ai.mit.edu, Scott Ribe at
scott_ribe@killerbytes.com wrote on 2001.01.26 11:24 AM:

> OK, does anybody remember the URL for that article by Scott Meyers on
> increasing encapsulation that sounded sooo much like an endorsement for
> the Dylan way of doing things?

Yes, here's a copy of my post about it, with an additional comment after:

---------------------8<---------------------
Message-ID: <B5C958A8.73A3%page@best.NOSPAM.com>
Date: Wed, 23 Aug 2000 10:32:08 -0700

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."
[...]
---------------------8<---------------------

In other words, the complete interface for a class is never completely in
the class definition anyway. Namespaces (and documentation, of course)
provide higher-level ways to organize and describe interfaces.

-- 
Chris Page

let mailto = concatenate( "page", "@", "best.com" );