[plt-scheme] "appending" to classes rather than extending

From: Matthias Felleisen (matthias at ccs.neu.edu)
Date: Fri Mar 7 09:35:08 EST 2008

On Mar 6, 2008, at 10:54 PM, Doug Orleans wrote:

> Matthias Felleisen writes:
>> The purpose of a class is to protect some invariant relationship
>> among the fields and methods.
>
> The purpose of a module is to protect invariant relationships.  The
> purpose of a class is polymorphism and inheritance.  That's how I see
> it, anyway.  Of course, many languages don't have modules, so they use
> classes for encapsulation too.  In PLT Scheme, what does the
> encapsulation of classes give you that modules and units don't already
> provide?

Every single construct in a language that allows programmers to
introduce a "service/client" relationship encapsulates and protects
some property:

1. lambda. If it weren't so, why do you think dynamic scoping  
disappeared?
[service: evaluation of a parameterized variable expression, effects;
client: call sites]

2. module.
[service: bundling of definitions, partial exports; client: importing  
modules]

3. class. If you don't want AT LEAST foo.bar => method not understood,
why bother introducing a class from which you can create objects?
[service: bundling of definitions and methods, plus dispatch;
client: instantiation, inheritance]

4. methods. like lambda. the scope is the class.
[service: see lambda, plus scope of class; client: method invocation  
site]

5. units.
[service: bundling of parameterized definitions, effects;
client: compounding and invocation sites.]

Every time you can draw a boundary between 'us' and 'them', the
boundary exists to hide something and to make something visible.
There exists a relationship between those and programmers
reason about it. Whether they call this invariant or not doesn' t
matter. They reason with simplified assumptions, the way an
engineer uses Newtonian mechanics on occasion (though I am
afraid the typical programmer's reasoning is much more naive).
If you usurp this reasoning, you are endangering the integrity of
the code. Just because it tests out 100 times means nothing if
it fails the 101st time when it matters.

I am not advocating proving things correct.

I am only advocating not deliberately destroying the little
integrity of reasoning that exists in programs.

-- Matthias





Posted on the users mailing list.