Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!microsoft!alonzo
From: alonzo@microsoft.UUCP (Alonzo Gariepy)
Newsgroups: comp.lang.eiffel
Subject: Re: The indexing clause
Message-ID: <92@microsoft.UUCP>
Date: 18 Jul 89 20:33:30 GMT
References: <180@eiffel.UUCP> <120001@gore.com>
Reply-To: alonzo@microsoft.UUCP (Alonzo Gariepy)
Organization: Microsoft Corp., Redmond WA
Lines: 83

In article <120001@gore.com> jacob@gore.com (Jacob Gore) writes:
>/ comp.lang.eiffel / bertrand@eiffel.UUCP (B. Meyer and P. Stephan) / Jul 13, 1989 /
>>       deferred  class  does  not have a representation. For
>>       such a class the clause should not contain an   entry
>>       ``representation: none'' but simply no entry with the
>>       index ``representation''. A reasonable query language
>>       will make it possible to use a query pair of the form
>>       <representation, $NONE$>, where $NONE$  is  a special
>>       value indicating absence.
>----------
>
>Why?
>
>It is not clear to me that in a database that the combined indexing entries
>will form lack of information must imply negation.  Why is it better to
>assume that the lack of "representation:" means "$NONE$" rather than
>"$UNKNOWN$" (or, perhaps, simply "$UNSPECIFIED$")?
>
>--
>Jacob Gore	Jacob@Gore.Com		{nucsrl,boulder}!gore!jacob

I have to agree strongly with Jacob Gore.  I have found it very 
very convenient to distinguish between an index with no value and 
one that is not present.  The existence of a value such as "none"
provides a third distinction.

The meaning of an index that is not present is that the classification
has no relevance to the object (in this case, an Eiffel class).  For
example, "RetrievalMethod:" has no relevance to floating point numbers,
and "EncodingStandard:" has no relevance to arrays of cake recipes.

An index that is present, but that has no value, might indicate a variety
of things: the value has not been put in yet; the proper value has yet
to be determined; the value is null (not to say irrelevant); the value
is some kind of default.  Eventually, these indexed Eiffel classes will
exist in a database containing both finished classes and those under
development.

The alternatives for abstract classes might then be:
Representation: deferred    -- specifies subclass responsibility
Representation: none        -- there is no representation 
Representation:             -- unspecified 
< missing altogether >      -- Representation?  What's that?

This is not the best example however.  

Consider an abstract class COMPRESS that deals with compressed data.  
It leaves the actual compression method to be defined in a subclass.
For illustration we will have three subclasses of COMPRESS called
RUNLENGTH, HUFFMAN, and PLAINTEXT.  One can then imagine the following
indexing:

class COMPRESS indexing

Representation: deferred;    -- abstract class
Compression:    deferred;    -- subclass responsibility
...

class RUNLENGTH indexing

Representation: byte, array;
Compression:    runlength;
...

class HUFFMAN indexing
Representation: word, array;
Compression:    two byte, huffman;
...

class PLAINTEXT indexing
Representation: character, array;
Compression:    none   ;   -- this subclass isn't actually compressed
...

class LMPLZFF indexing
Representation: 12bit, bitfield, array;
Compression:           ;   -- blank. I can't remember how to spell this.
...

================
Alonzo Gariepy
alonzo@microsoft
================