Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!emory!stiatl!srchtec!johnb
From: johnb@srchtec.UUCP (John Baldwin)
Newsgroups: comp.lang.c++
Subject: Addition to const (long) [was Re: const is not object-oriented]
Summary: lengthy discourse on a language addition.
Keywords: verbose, obfuscated, windy, prolixity
Message-ID: <297@srchtec.UUCP>
Date: 13 Nov 90 18:49:22 GMT
References: <1990Nov9.181408.23110@odin.corp.sgi.com> <13050@cadillac.CAD.MCC.COM> <1990Nov12.184240.23430@odin.corp.sgi.com>
Organization: search technology, inc.
Lines: 82

In article <1990Nov12.184240.23430@odin.corp.sgi.com> linton@sgi.com
 (Mark Linton) writes:
>All the responses so far have essentially said the same thing:
>"we don't care what const really means, we'll use it how we want".
>  [...excerpted...]

>  We can

>    (1) continue to abuse its meaning as many are already,
>	using casts to circumvent compiler attempts to enforce the meaning

>    (2) change the meaning of const to remove the storage semantics

>    (3) find another way to do what we want


Perhaps there is another way: in the past, when syntax and symantics clashed,
language designers (and users, and implementors) sought ways for the
programmer to syntactically specify the semantics desired.

I believe I have an approach that may allow this.  The approach is to
add the keyword "adjunct" to the language: either as a type *modifier*
(like "const") or as a class visibility restriction (like "public",
"protected", and "private").

Webster's defines the word "adjunct" in its noun form as...
   1. "something joined or added to another thing but not
       essentially a part of it."

This is exactly what we want: data which is "joined to" an object, but
"not really a part of it."  I envision the following usage and treatment...

class some_list       // some list of items we have
{
public:
    long   sum() const;
    .
    .
    .

private:
    // some private data

adjunct:
   bool   sum_is_current;
   long   computed_sum;
}


Now, the sum() method can still be considered a const function,
  ***since it doesn't modify any of the "actual" object!***

Hopefully, my intent is apparent: adjunct data may be changed without
affecting the "const-ness" of the rest of the object.  Stated another
way, const member functions may change adjunct data, but not any
other member data.

The other usage would look like this:

class some_list {
public:
   long   sum() const;

private:
   // data

   adjunct bool   sum_is_current;
   adjunct long   computed_sum;
};


I'm not sure this is the way to go, however, because "const-ness" applies
to data other than object member data, but "adjunct-ness" does not.


Comments?    [Bat-anti-flame-suit *on*]


-- 
John T. Baldwin                     | "Pereant qui ante nos nostra dixerunt!"
Search Technology, Inc.             | (A plague on those who said our good
johnb%srchtec.uucp@mathcs.emory.edu |  things before we did!)