Properties instead of Java-style getters and setters?

[Bill Baxter]

On Thu, Sep 4, 2008 at 7:38 AM, Frank Benoit <keinfarbton at googlemail.com> wrote:
> Robin Kreis schrieb:

>> What I'm concerned with is DWT carrying over some of the limitations of
>> Java.  While I do like Java and also SWT, I dislike the idea to make
>> certain decisions just because the people behind SWT had no other
>> options.
>>
>> Although DWT appears to fit into D quite well, I'd love to see real D
>> properties replace getters and setters, or at least alias them.  Those
>> only exist in SWT because Java has no other property support. Getters
>> and setters are treated like properties in Java, for example in GUI
>> builders, refactoring tools or scripting languages like Jython.
>>
>
> I do not like the D properties. I also do not like operator overloading.
> I think it is much more important to see what is going on. If it looks
> like a field, it should be a field. But that is a matter of personal
> taste. :)
>
> What priority do others give to this?

I think it's not worth the trouble.   At least at this stage.  I think
DWT will still be a toolkit with a very Java-esque feel to it because
of the heavy use of  anonymous classes and other things.  I think such
issues will persist unless you put a lot of effort into it.  There's
also the documentation issue.  Right now you can pretty much go by
what the SWT docs say, but if D-style properties are added that will
no longer be the case.

In any event D properties have an ambiguity problem when it comes to
taking function addresses.  &myProperty could give you a pointer to
the getter or the setter, just depends on which one appears first in
the class.  For that reason I'd want to keep the distinctly named
getters and setters.  So that leaves you with making aliases.  But
making a heap of aliases just to avoid typing 'get' and 'set' and just
to make duplicates of a bunch of methods that already work fine,
doesn't seem like such a winning proposition to me.

> A problem could be, that the identifier for the property can conflict to
> private methods and fields.
> If the field is renamed to solve that conflict a later upgrade merge can
> introcude hard to find errors.

That could be fixed by a slightly intelligent search and replace on
the Java sources prior to merging.  Just would require keeping a list
of renamed variables.  Don't you already have to do a fair amount of
preprocessing on the Java before merging?

> Can D2 add properties with "unified function call syntax" ? (does this
> feature already exist?)

I don't think the unified function call syntax has been implemented yet.

--bb