[254] in Coldmud discussion meeting

Re: Connection()

daemon@ATHENA.MIT.EDU (Wed May 18 06:43:57 1994 )

From: stewarta@netcom.com (Alex Stewart)
To: colinm@extro.ucc.su.OZ.AU (Colin McCormack)
Date: Wed, 18 May 1994 01:35:03 -0700 (PDT)
Cc: coldstuff@MIT.EDU
Reply-To: coldstuff@MIT.EDU
In-Reply-To: <199405172035.GAA12040@extro.ucc.su.OZ.AU> from "Colin McCormack" at May 18, 94 06:35:47 am

> This would require each function to know, for the uttermost descendant of
> a call tree descending from it, that some function will need stdio.
> Does this break information hiding?  How about for virtual functions?

I'm afraid your defense is based on another bad design practice, namely the
inclination to access stdio from within subroutines and functions, which in
itself breaks encapsulation.  The point is that in a proper system design,
nothing except the topmost execution level (the user-interface level) should
ever access stdio anyway.

In a proper design, all output information should be returned from subfunctions
as return values, and output by the topmost calling function if appropriate.

> There is a primitive which makes use of connection information,
> echo() or somesuch... are you suggesting that this is not needed,
> or rather that the appropriate place for accessing current connection
> is the server, and only there?

Actually, the current functioning of echo(), in my opinion, is something to be
changed, rather than emulated.  In my opinion, echo() should only work when
this() is an object with a current connection bound to it, and should echo to
all connections bound to the current object, thus preserving encapsulation and
a consistent connection<->object interface.

> You can stop people writing bad code by making a language that can't 
> express `bad constructs', but that does not make people write good code.

I do not propose any of these measures as mechanisms for controlling
programming styles.  I am fundamentally opposed to any decisions based solely
on one person's aesthetic for "good code", in fact.  What I'm discussing here
is not programming issues but system design issues.  Exceptions to the base
principles of a system are rather like cutting through a support beam to get a
little more ventilation.  It adds a little convenience but weakens the overall
strength and power of the system, and eventually it ends up caving in on you.

There are examples of this, if you look for them, in nearly all major computer
system designs (but particularly in they type of general-purpose systems that
M*s have become over the years).  I don't want ColdMUD to be just another
example..

It should be noted that I am not saying anything about whether the base
principles of ColdMUD are good or bad, I am simply saying that if they aren't
good enough, patching them with exceptions will most likely only make matters
worse in the long run.  If changes are really necessary (which in my opinion
they aren't for this type of thing), then the whole foundation for the system
should be reconsidered as a whole.

Anyway, that's my tirade for the day :)

-Riche