Extension suggestions

[Ivan Schreter <ivan at shadow dot sk>]

Hello,

I would like to suggest a features for egcs, namely properties, as they
are found in Delphi or Borland C++ Builder and signal-slot mechanism
as found in Qt or Gtk--.

What is a property? Property is an extension of a field. Properties can
be read-only, write-only or read-write. They serve for protecting class'
fields from invalid accesses and can trigger actions on property read or
write. Anyway, they are a neat thing. Consider this code:

class Circle : public Shape {

private:
	int f_radius;

protected:
	void setRadius(int r);
	void redraw();

public:
	property int radius = { read = f_radius, write = setRadius, default = 1 };

}

Circle::setRadius(int r) {
	f_radius = r;
	redraw();
}

....

Circle test;

test.radius = 5;

Now, you can access the radius of the circle using test.radius. When you set
test.radius, it will actually generate call to setRadius(rvalue). When you read
test.radius, it will generate read of private field f_radius. Or, there might
be a function returning int associated with read, so read would call that
function and return computed value. This way, some fields can be actually
computed.

As for default, it was in C++ Builder intended for builder API, so that
visual (and other) components are initialized correctly when created. It
might not be needed for the first implementation... Borland has also some
more specifiers for property descriptions.

Also, >> and << operators for the class should read/write properties, but
that's the responsibility of an application programmer.

The implementation of properties is pretty much straightforward:

- when property definition is encountered, internally create one or two
  functions (depending which access specifiers were used), like:

  public:
	inline proptype __read__propname() {
		return whatever_was_specified_for_read;
	}
	inline void __write__propname(proptype value) {
		whatever_was_specified_for_write(value);
	}

- record property definition in name table
- when use of property is encountered, convert it to call to __write__propname
  if used as lvalue or to __read__propname if used in expression.

Another suggestion would be to implement directly in compiler typesafe
callbacks, which can be somehow connected to one or more receivers (object's
methods). There are two implementations available now: Troll's Qt signal-slot
mechanism (www.troll.no) and Gtk--'s signal mechanism (www.gtk.org), both of
them need special preprocessor, though, and are somewhat cumbersome, but usable.
Again, implementation of this would be relatively straightforward - when
declaring a signal, it would actually define a linked list with receivers and
one method that calls each receiver when signal function is called.
The connection function would be also generated on-the-fly with compiler
checking for correct type of receiver method. Then, emitting a signal
(potentially with some parameter) would lead to call of that signal method.
See Qt's implementation of signal-slot mechanism and you will see what I
mean. It's really interesting one.

So, what do you think?

				Sincerely,

					Ivan Schreter
					ivan@shadow.sk