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