Newsgroups: rec.arts.int-fiction
Path: news.duke.edu!newsgate.duke.edu!news-hog.berkeley.edu!ucberkeley!news.maxwell.syr.edu!nntp.abs.net!uunet!dca.uu.net!ash.uu.net!world!not-for-mail
From: buzzard@TheWorld.com (Sean T Barrett)
Subject: Re: classes and attributes
Sender: news@world.std.com (Mr Usenet Himself)
Message-ID: <Gunwos.M8r@world.std.com>
Date: Tue, 16 Apr 2002 13:12:27 GMT
References: <ubbqmqn7q2ddb4@corp.supernews.com> <a9dltd$lb3$1@foobar.cs.jhu.edu> <vzNu8.4000$%L2.2103902487@newssvr21.news.prodigy.com> <a9gtfh$t0s$4@foobar.cs.jhu.edu>
Nntp-Posting-Host: shell01.theworld.com
Organization: The World Public Access UNIX, Brookline, MA
X-Newsreader: trn 4.0-test72 (19 April 1999)
Lines: 49
Xref: news.duke.edu rec.arts.int-fiction:103251

L. Ross Raszewski <lraszewski@loyola.edu> wrote:
>The ability in TADS to make an instance variable indistinguishable
>from a method which returns one has always intrigued me, since it's
>something that no other language I know of does, and with good reason.

Inform sort of does this, in reverse, by allowing you to call
as-a-function an instance variable. See the top paragraph of
page 63 of the DM4. (Also see PrintOrRun() and other such
routines used heavily by the library.)

SELF does exactly what you're talking about, but it's a natural
generalization of what Smalltalk does.

Smalltalk doesn't allow access to instance variables externally;
everything has to go through "accessor" methods. This is a
fundamental issue of data hiding; if you allow access to instance
variables, you haven't merely exposed an interface, you've exposed
an implementation. It is no longer possible to modify the classes'
implementation, or create a new implementation of the subclass,
in which the implementation strategy is radically different.
(You can try to hack it by back-supporting the 'old' instance
variables and converting them, but you do extra checking and
your code blows up in complexity.)

So SELF basically introduces "default" accessor methods for
instance variables if you want them--getter and setter 'methods'
for fetching and storing to the apparent instance variables.
But you can redefine the class, or inherit and override, and
replace these getter and setter methods to do something totally
different, while the calling code will still seem to be getting
and setting instance variables. (IIRC this means Self even hides
the implementation of a class from its subclasses and itself,
so subclasses trying to access the instance variable get sent
through the appropriate methods. This has all sorts of interesting
effects that even further limit how much you have to change when
you change an implementation.)

I'm not totally thrilled with this, on the principle of least
surprise (what appears to access an instance variable does some
arbitrary thing instead--basically operator overloading), but if
you're going to allow access to other object's instance variables
at all, I don't think you can do anything other than this and
still support a strict OO style. Tads, sadly, does not go far
enough, since it doesn't support setter methods.

But in my opinion the "for good reason" in your text
should be "because they are very poorly thought-out".

SeanB
