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.

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.

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