• Robin Kreis (11/11) Sep 03 2008 I've been looking for a fine GUI toolkit for a while now, and from what
• Frank Benoit (14/28) Sep 03 2008 I do not like the D properties. I also do not like operator overloading.
• Bill Baxter (22/45) Sep 03 2008 I think it's not worth the trouble. At least at this stage. I think

Robin Kreis <robinkreis gmx.de> writes:

I've been looking for a fine GUI toolkit for a while now, and from what
I've seen, DWT looks really fine.

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.

Frank Benoit <keinfarbton googlemail.com> writes:

Robin Kreis schrieb:
 I've been looking for a fine GUI toolkit for a while now, and from what
 I've seen, DWT looks really fine.
 
 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?

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.

Can D2 add properties with "unified function call syntax" ? (does this
feature already exist?)
If so, i think, those properties could be added in a clean way. Because
they only act on the public API.

"Bill Baxter" <wbaxter gmail.com> writes:

On Thu, Sep 4, 2008 at 7:38 AM, Frank Benoit <keinfarbton 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