Newsgroups: rec.arts.int-fiction
Path: news.duke.edu!newsgate.duke.edu!nntp-out.monmouth.com!newspeer.monmouth.com!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: <GuL6Az.8rx@world.std.com>
Date: Mon, 15 Apr 2002 01:47:22 GMT
References: <ubbqmqn7q2ddb4@corp.supernews.com> <MPG.1722951a7042136d989d3f@news.cis.dfn.de> <98ef019f.0204140015.1410c01b@posting.google.com> <a9cm3m$833$2@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: 54
Xref: news.duke.edu rec.arts.int-fiction:103143

L. Ross Raszewski <lraszewski@loyola.edu> wrote:
>Yeah. THere's always been some debate over whether it's a worthwhile
>distinction. Basically it comes down to us because there are technical
>reasons that it's desirable to have certain boolean instance variables
>represented differently at the VM layer.

There are *debatable* technical reasons. I assume you're primarily talking
about size. With 32 possible boolean instance vars, and the average object
having 1.5 of them, and each defined property requiring only 16 bits (i.e.
being undefined qualifies is interpreted as 'false' in this context),
there's not necessarily a size win. If the cost of storage is 32 bits
(property name + value), the break-even point is 1 boolean attribute
per object with 32 possible boolean attributes. (I forget the exact
number the Z-Machine has.) Most objects in my games have none, but I
don't know the actual average, since I do have the occasional object
which has openable lockable locked wearable worn pluralname,

With inheritence implemented to be size-efficient many of these properties
can be stored on an object effectively for free. (Things like openable,
wearable, animate, which don't tend to change dynamically.)

It's also misleading to say that technical reasons for wanting this
in the implementation necessarily means it has to be exposed in the
language. It's possible to create VM implementations that secretly under
the hood compress objects and datatypes in various ways; I described
this idea in one of my documents talking about implementation
strategies for Slux, my T3-esque VM:

  Multi-mode compression: Arrays and objects may also compress
  themselves in non-standard ways. Arrays could recognize that they
  are homogenous byte arrays, and switch to a different internal type
  flag and store the data that way. Suggested compression modes:
  array of signed bytes, array of unsigned bytes, array of bits, array of
  16-bit elements. Also, by giving these distinct internal type codes,
  it's possible to alter the implementation of most array primitives to
  directly use these arrays, rather than force them to decompress. For
  example, arrayset() on a bitarray, iff the value is 0 or 1, can find the
  right bit and set/clear it; if the value is not a bit but is a byte, it can
  be promoted to a byte array. Caution should be used in
  promoting/demoting types, to avoid excess overhead; a good time to
  promote/demote is at the same time the object would normally be
  compressed because it's no longer being actively used. Note that this
  is entirely a size optimization, not a speed optimization. But if all
  small-memory-targetted VMs used this strategy, programmers and
  compiler authors could assume that using an array but never storing
  anything but 0 or 1 into it will actually be small.

Such a VM is only slightly more complicated and slightly slower (if
at all) than one which uses an explicitly differently syntax for
operating on the different types of data storage facilities. (Admittedly,
this requires that the system support dynamic typing, which Tads does
but the Inform does not completely.)

SeanB
