Totally agree. This is one of the design limitations I'm trying to fix. 
Actually, PWS was not designed to be a singleton. I'm not entirely sure,
but it appears that its ancestor had this limitation, so it propagated
to PWS. And it is now (a few months/years already?) that people have
made a significant use of PWS and understand what is missing.

--
Bolot Kerimbaev
College of Computing
Atlanta, GA 30332-0280


On Thu, 6 May 1999, Andrew C. Greenberg wrote:

> >Currently, PWS is a class-side application. Close inspection reveals
> >that PWS class is a web server, whereas a PWS instance is actually an
> >HTTP request. Thus, yes, only one PWS per image is possible.
> >
> >I'm currently working on restructuring the PWS to support, among other
> >things, multiple servers per image.
> >
> >One trick to run multiple PWS's is to subclass it. But you may need to
> >check out direct references to PWS and replace them with self or self
> >class (for PWS class and instance respectively) or, for other objects,
> >create a way to reference the correct server.
> 
> According to Ralph Johnson, this is a shanda (translation: really 
> groty and losing thing).  Using classes as a vehicle to enforce 
> singleton's is one thing, but the difficulty with that approach is 
> precisely that it invites problems when reusers desire to produce 
> multiples instances in the distant future.
> 
> His specific example of the recipe for disaster in the "Classic 
> Smalltalk Bugs" memo is precisely what is suggested here: using 
> subclassing of a class-as-singleton class to achieve multiple 
> "instances" thereby.
> 
> Perhaps its time to recognize the truth of the matter, and call a 
> class generating server instances Server, and the class generating 
> request instances Requests.  Enforce singletons in a more 
> conventional manner, while still paving the way for later 
> applications that might find plural servers to be a "real good thing 
> tm."
> 
> While there is an appealing compactness of putting PWS and its 
> request instances together, that compactness really doesn't buy 
> anything, and invites confusion later.  As a stylistic matter (from 
> one barely an adolescent in Smalltalk coding), Professor Johnson's 
> remarks seemed salient.
> 
>