DIP4: Properties

Daniel Keep daniel.keep.lists at gmail.com
Fri Jul 24 01:48:35 PDT 2009


Sorry; posted without going over the Description section.  :P

Again, automatic storage just rubs me the wrong way.  Less magic, please.

---

Without automatic storage, there's a fairly simple way to make it
visible outside the property; move the "auto value;" declaration outside
and make it "T _blah;" or something.  Not pretty, granted, but
consistent and means we don't have to muck with traits or special
syntax.  It's also *obvious* where stuff is accessible from.

---

struct Property(T)
{
    T delegate() getter;
    void delegate(T) setter;

    T get()
    {
        return enforce(getter, new MissingGetterException)();
    }
    void set(T v)
    {
        enforce(setter, new MissingSetterException)(v);
    }
}

The exceptions shouldn't need explanation.  :)

---

Interacting with inheritance is tricky.  I think what should be done is
this:

class A { int foo { get; set; } }

Would generate the following hidden functions:

A.__property_foo_get
A.__property_foo_set

Then, this:

{
    A a;
    auto p = &a.foo;
}

translates to this:

{
    A a;
    Property!(int) p = {
        getter:&a.__property_foo_get,
        setter:&a.__property_foo_set};
}

This should allow class implementations to add a setter to read-only
properties specified in either an interface or base class.

(Incidentally, the internal storage could be __property_foo_(name) or
something.)

As for defaults: public.  Properties are usually defined for public
interfaces; if it was private, you might as well just use a field.

---

Again, I don't like having "set" be magical.  _argptr and _arguments are
bad enough as it is, please let's not add more invisibly defined magic
identifiers!

---

Regarding your cons: get and set mustn't be made keywords; they're too
short and useful.  Using in and out is actually a pretty good idea.

Come to think of it... would it at all be useful to be able to expose a
ref property that just exposes an underlying field?

Your note regarding array properties and extension methods was one I
hadn't considered.  It should DEFINITELY be given thought.



More information about the Digitalmars-d mailing list