Newsgroups: rec.arts.int-fiction
Path: gmd.de!xlink.net!howland.reston.ans.net!usenet.ins.cwru.edu!news.ecn.bgu.edu!wupost!waikato!canterbury.ac.nz!huia!greg
From: greg@huia.canterbury.ac.nz (Greg Ewing)
Subject: Re: Design of a New Language: 2
Message-ID: <CGAuqF.42C@cantua.canterbury.ac.nz>
Nntp-Posting-Host: huia.canterbury.ac.nz
Reply-To: greg@huia.canterbury.ac.nz (Greg Ewing)
Organization: University of Canterbury, Christchurch, New Zealand
References: <CG96Mq.1xs@cantua.canterbury.ac.nz>) <2bqtv5INN81f@life.ai.mit.edu>
Date: Wed, 10 Nov 1993 23:32:38 GMT
Lines: 61

In article <2bqtv5INN81f@life.ai.mit.edu>, dmb@min.ai.mit.edu (David
Baggett) writes:
|> TADS could be better in this regard, but is nevertheless quite adequate.

The whole idea behind this project is to make it *more* than just
"adequate". So, how could Tads do it better?

|> Many people find flaws in adv.t and fault TADS. [...]
|> The point is that adv.t could be rewritten to handle all sorts of
|> funtionality.

I know, and I agree that this is a desirable ability to have.

|> In the 16 years I've been programming I don't think I've ever seen better
|> documented code than adv.t,

Okay, perhaps that comment was too harsh. If you just want to use the
existing classes, or make simple extensions of them, the comments in
adv.t are quite adequate.

But if you want to customise anything more extensively, you find yourself
becoming concerned not just with *what* things do, but *how* they work.
At this point, depending on how well the class library has been designed,
things can become very difficult.

One of the main problems is that in Tads there is no clear distinction
between the public interface of the library and internals that you're
not supposed to mess about with. If you want to override a particular
behaviour, often there are several ways of going about it, but some of
them will cause undesirable side effects, and there's no easy way of
deciding which is the "right" way.

Making non-trivial extensions to the Tads library thus becomes a very
stressful activity, because you never know whether what you're doing
is going to cause something else to break. And if you're brave
enough to include someone else's extension...

I've encountered the same problem with every object-oriented system
I've used. The fact is, designing a class library for flexibility
and extensibility, and doing it well, is HARD!!!!! (Did I emphasise
that enough?) It is definitely not something you learn to do in an
afternoon. And you have to document not just how to use it, but
how to extend and modify it.

The point is, if you are going to rely on a class library to embody
the bulk of your default behaviour, you need to put as much care and
thought into its design as if you were building it into the language
itself. Saying "Oh, well, it's just a library, so if you don't
like it you can change it" is Not Good Enough.

|> Dave Baggett
|> __
|> dmb@ai.mit.edu            Boot up, log in, drop out.             MIT
AI Lab                                                                  
|> ADVENTIONS: We make Kuul text adventures!  Ask about Unnkulian 1, 2, 0, 1/2
|>   PO Box 851 Columbia, MD 21044 USA / CIS: 76440,2671 / GEnie: ADVENTIONS

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of Japan Inc.|
greg@cosc.canterbury.ac.nz	   +--------------------------------------+
