Subject: Half-baked data type ideas

From: [email-masked]
Date: Thu, 23 Jan 1992 16:24:41 -0800

JoeFeedback and I are toying with a Minimal.db.  As well as coming up
with a weird restructuring of :tell/:announce, we started thinking
about names for utility objects.  We came to the conclusion that
instead of having $string_utils and $list_utils, we should just have
$string and $list, and in fact, have $integer and $error and $object
as well.  These would inherit from $type, which would define protocol
for operations like :to_string() and :from_string() and like that.

$type would mostly be an abstract superclass; we talked about making
$type effectively call `self subClassResponsibility' for most of its
methods.

We also considered $alist, a descendent of $list, as a place to put all
those nifty assoc-related verbs.

Since Haakon assured me that it was OK to air half-baked ideas on
MOO-Cows, here's one:

Hack the server to allow verb calls on non-objects.  Instead of
`1234:to_string()' causing a type error, it would route the call to
`$integer:to_string()'.  Either 1234 would be added to the
:to_string() argument lists, or `this' would be set to 1234.  Similar
redirection would be done for the other data types, except for
objects, obviously.

Unfortunately, this doesn't provide any nice way to provide for
user-defined data subtypes.  All instances of the MOO data structure
type, the list, would have the same method suite.  $alist's would have
the same methods as $list's.  So here's half-baked idea number two:

Associate a `class' attribute with certain lists.  Make the class
accessible through a few new primitives.  Lists would otherwise appear
exactly the same, except when verbs are called on them.

Alternative idea:  Treat lists of the form {E_TYPE, #class,
internaldata, internaldata, ...} differently in the verb dispatcher.
Refer all calls to #class.  This has the disadvantage of disallowing
implicit list operations on lists that start with E_TYPE (let me know
if you've ever seen one :-) but would still allow explicit
`$list:foo({E_TYPE, ...})' data typing calls.

Lemme know what you think.  If you have any ideas for cores built from
Minimal.db, tell me or JoeFeedback.

       ---Jonny

  // Jay Carlson
\X/  [email-masked]

To subscribe to the MC68HC11 list, email to [email-masked].

---

From: Larry Masinter <[email-masked]>
Date: Thu, 23 Jan 1992 18:46:32 -0800

It is a mistake to think of $alist as a kind of a $list. Lisp systems
that tried to do this failed, since they aren't proper subtypes, it is
reasonable to construct something "as a list" and then treat it "as an
alist", and deciding whether any arbitrary list structure could be
treated "as an alist" isn't easy. There's a limit to what you can
expect from a type hierarchy; you wouldn't expect to have $prime or
$even, even though there are sets of primes and evens as subsets of
$integer.

It is OK to disallow user-defined data subtypes of built-in types. It
makes no sense to define subtypes of $integer, since it isn't an
extensible type. I would suggest instead that you make a type called
$number, and make $integer inherit from $number. Users can define
other kinds of $numbers, too. Things that really made sense for
moo-numbers only would go to $integer, while other methods would just
go on $number. 

Alternatively, you might just define $string and $integer to be
abstract, and $moo_string and $moo_number to be the classes that are
called.

MOO already has a nice class system, and most of the generality you
need can be done without hacking up another one with special lists
that start with special codes.