Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!zaphod.mps.ohio-state.edu!usc!jarthur!uunet!hsi!stpstn!cox
From: cox@stpstn.UUCP (Brad Cox)
Newsgroups: comp.object
Subject: Re: the need for classes as objects (closed vs. open universes)
Message-ID: <5516@stpstn.UUCP>
Date: 1 Sep 90 00:47:59 GMT
References: <2259@esquire.UUCP> <55679@iuvax.cs.indiana.edu>
Reply-To: cox@stpstn.UUCP (Brad Cox)
Organization: Stepstone
Lines: 31

In article <55679@iuvax.cs.indiana.edu> kitchel@iuvax.cs.indiana.edu (Sid Kitchel) writes:
>yost@esquire.UUCP (David A. Yost) writes:
>
>| I've heard lispers and smalltalkers say that
>| the ability of their languages to create
>| classes at runtime is very powerful, even
>| necessary, and that therefore statically-
>| classed languages (shall we say) that don't
>| allow this (e.g.  Eiffel, C++) are inferior.
>
Classes as objects, like dynamic binding, are entirely unnecessary
if your application domain can be approximated as a closed universe
in which everything is known when the universe is created by the compiler
and linker. Examples of closed universes are most conventional programs,
especially those that are built by a single programmer

Class as objects, like dynamic binding, become essential when your application
domain cannot be approximated as a closed universe, but must be responsive
to things entering or leaving after the application has been constructed
by the linker, or even while it is running. Examples of open software
universes are systems where objects are persistent, distributed, and/or
shared, where many programmers are involved, or when components are to be
aggressively reused across diverse (poorly-coordinating) organizations.

Examples: an automobile engine is a closed universe. The passenger 
compartment and trunk are open universes.

-- 

Brad Cox; cox@stepstone.com; CI$ 71230,647; 203 426 1875
The Stepstone Corporation; 75 Glen Road; Sandy Hook CT 06482