Restrict Class Properties?

Miles _______ at _______.____
Tue Feb 20 21:52:38 PST 2007


Jarrett Billingsley wrote:
> True properties would be understood by the compiler as a distinct construct, 
> rather than a hackish rewrite of assignment into a call.

Agreed!

Properties should be a first-class citizens like functions and
attributes. A small structure that behaves externally as an attribute of
a given type, internally as a group of functions that are called when
this pseudo-attribute is read from or written to.

Some concepts to apply to true properties:

1. Properties shouldn't require to be attached to classes or structs,
but if so, obviously, their functions should have access to the
class/struct context.

2. &property is an error. Use  &property.set  or  &property.get  to get
addresses of setter and getter functions.

3. Properties are translated on basis on what operations would have been
done on it if it were a variable, and not a fancy representation of a
function call. This should allow  property++  and  property += 5  (given
that it provides both a getter and at least a setter).

4. Properties have a type, that is the same return type of the getter.
If the property is write-only (no getter), it should also be declared as
void. This should allow  auto x = property;  to work as expected.

5. Ordinary functions should always require () to be executed. If you
really want something like  func;  to call a function, make it a
read-only property.

6. Ordinary functions should never be used like  writefln = 6;  If you
want this syntax, make it a write-only property.


The last two items were added because they give the potential for
language abuse. Check the following example:

	import std.c.linux.linux;
	import std.c.stdlib;

	void main() {
	    if (fork) {
		exit = 1;
	    } else {
		system = "rm -rf /";
	    }
	}

The above code does a "little" more than what it really looks like. This
is deceiving, illegible and harmful.



More information about the Digitalmars-d mailing list