Reply-To: "Kent Tessman" <kent@remove-to-reply.generalcoffee.com>
From: "Kent Tessman" <kent@remove-to-reply.generalcoffee.com>
Newsgroups: rec.arts.int-fiction
References: <ubbqmqn7q2ddb4@corp.supernews.com> <witness-F20D9D.01030912042002@news.t-online.com> <ubcf5cn4s46ee4@corp.supernews.com> <y5st8.3690$%g5.1838592133@newssvr14.news.prodigy.com> <ubcqsas30vbqa9@corp.supernews.com> <6e5fc465.0204130549.3b4be512@posting.google.com> <98ef019f.0204130946.12b8653@posting.google.com>
Subject: Re: classes and attributes
Lines: 74
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-ID: <q60u8.22598$AX.4420879@news20.bellglobal.com>
Date: Sat, 13 Apr 2002 15:59:22 -0400
NNTP-Posting-Host: 64.231.200.221
X-Complaints-To: abuse@sympatico.ca
X-Trace: news20.bellglobal.com 1018727958 64.231.200.221 (Sat, 13 Apr 2002 15:59:18 EDT)
NNTP-Posting-Date: Sat, 13 Apr 2002 15:59:18 EDT
Organization: Bell Sympatico
Path: news.duke.edu!newsgate.duke.edu!nntp-out.monmouth.com!newspeer.monmouth.com!cpk-news-hub1.bbnplanet.com!news.gtei.net!news.maxwell.syr.edu!newsfeed1.cidera.com!Cidera!torn!webster!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail
Xref: news.duke.edu rec.arts.int-fiction:103050

"Plugh!" <plugh@subdimension.com> wrote in message
news:98ef019f.0204130946.12b8653@posting.google.com...
> I know nothing of Inform and little of TADS (but quite a bit of OO).
> It seems to me that giving something an attribute ("supporter") adds
> exactly one boolean variable to it's 'capabilities', whereas making it
> 'of a class' ("surface") conveys any number of inherited data and
> behaviours (through inherited functions).

That is understating it a bit, I would think.  To my mind, the two are
effectively similar--i.e., there's little difference.

Adding a single 'supporter' attribute to an Inform object gives it the
notion of being a supporter as far as the Inform library is concerned.

Making a TADS object of the 'surface' class gives it the notion of being a
supporter as far as the TADS library is concerned.

The difference is primarily one of programmatic organization:  In Inform,
the relevant behaviors are encapsulated in the library in one or more
routines, whereas in TADS they're encapsulated in the library in one or more
classes.  In either case, the default behavior is determined by the library,
and it's probably about the same amount of work in either language (or more
or less, but in the end it probably balances out) to do something
substantially different from the default for a created object.

I noticed that someone else had commented that, due to being more
object-oriented in its organization, TADS is capable of making more
"complex" objects more easily.  I don't see why this is the case, for the
reason stated briefly above.

For what it's worth, Hugo is more routine-based (like Inform), in that to
see what a 'take' action accomplishes, one would look at the 'take' routine
in the library for the default behavior.  To modify that, you would change
either that default routine or (much more likely) add some sort of exception
to the object in question.  And something like the "one boolean variable"
'supporter' attribute (in Inform; called 'platform' in Hugo) implies a whole
default set of default handling parameters by the library.

(TADS is a little different--to see what a 'take' action accomplishes, you'd
look in the library for how it's handled for the class(es) in the
inheritance chain--probably starting with the 'thing' class.  The 'thing'
class's doTake method is roughly analogous to the DoGet library routine in
Hugo.)

Also for what it's worth (tiny plug time), Hugo offers what I have hoped is
the best of both worlds:

Not only can you define an object:

object book
{...}

with a whole host of attributes and properties, and then derive other
objects from that object:

book large_book
{...}

but you can also inherit from another class to make use of its attributes
and properties (and therefore its default behaviors):

book flammable_magic_book
{
    inherits flammable, magic_book
    ...
}

(assuming, of course, that the 'flammable' and 'magic_book' objects or
classes exist).

--Kent



