Xref: utzoo comp.lang.c++:13640 comp.std.c++:931
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!jarthur!petunia!kestrel.edu!gyro
From: gyro@kestrel.edu (Scott Layson Burson)
Newsgroups: comp.lang.c++,comp.std.c++
Subject: Re: Proposal: 'virtual' class members for C++
Message-ID: <1991May24.170014.17301@kestrel.edu>
Date: 24 May 91 17:00:14 GMT
References: <1745@culhua.prg.ox.ac.uk>
Organization: Kestrel Institute, Palo Alto, CA
Lines: 65

In article <1745@culhua.prg.ox.ac.uk> bill@robots.oxford.ac.uk (Bill Triggs) writes:
>I would like to propose a simple extension of C++ syntax
>which would allow 'soft' or 'virtual' class members to be
>simulated by member functions.
>
>It is considered good OOP style to use member functions to
>hide object state, and this is already possible in C++ using
>explicit member function calls. The current proposal aims to
>make this syntactically more pleasant by hiding member
>function calls as data member accesses.
>
>The basic idea is to allow
>
>	foo.f
>
>to be used in place of
>
>	foo.f()
>
>and
>
>	foo.g = <expression>
>
>to be used in place of
>
>	foo.g(<expression>)
>
>[...]

I like the basic idea of having things that look like member variables
that are actually member function invocations.  However, I don't like
the automatic conversion from one to the other, primarily because it
conflicts with another proposal of which I am very fond (that the
meaning of `foo.f', with no parens, should be the closure of `f' over
`foo').  How about this instead: we call these "virtual member
variables" and declare them something like this:

   class Foo {
	int x;
	int read_x() { return x; }
	void set_x(int new_x) { x = new_x; }
     public:
	virtual int value = { read_x, set_x };
   };

[Syntax notes: 1) This represents yet another overloading of
`virtual'.  I'm not too fond of the way `virtual' is overloaded
already, but this usage makes as much sense as either of the others.
2) The declaration syntax for virtual member variables requires no
grammar changes, but it does introduce an entirely different meaning
for the "initializer", which may be considered untasteful.]

Then one could write:

        Foo foo;
        foo.value = 3;          // invokes `foo.set_x(3)'
        cout << foo.value;      // invokes `foo.read_x()'

This requires only one additional declaration compared to the original
proposal, and has the virtue (in my eyes) of not being automagic.

Flames invited...

-- Scott
Gyro@Reasoning.COM