www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.dwt - Properties instead of Java-style getters and setters?

reply 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.
Sep 03 2008
next sibling parent 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.
Sep 03 2008
prev sibling parent "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
Sep 03 2008