Frank Benoit Wrote:

> 
> > Of course.
> > Probabely the Tango collection sources can be ported to phobos, so that a SWT user can use his prefered standard library  ?
> > have a look at the TIOPORT Forum / Bobef s message.
> > Bjoern
> 
> The ported SWT sources do not depend on tango. Only dejavu does.
> So it only needs /someone/ who does the reimplementation of dejavu with
> phobos. *blink*

Sorry about my ignorance, but I thought that Java SWT in general heavily depends on utils.collection and dejavu collection classes are just a thin wrapper using the Tango collection implementation ? Well, have to study the sources...
However, regarding the *blinking* hint; Will you give me some support ?

Bjoern

Hi, just think that instead of using dswt  SWT/D is more significant. Trutz Bla

torhu Wrote:

> Frank Benoit wrote:
> >> Do you mean to actually call it DWT, and do s/SWT/DWT/g on the source? I don't see what would be gained by doing that.  DWT and Tioport's SWT are not compatible, and I think it would be good to use different names for them too.  I don't see why it can't be called SWT even if it's ported to D.  The docs use SWT anyway.
> > 
> > Yes, the pure name is not really an advantage.
> > I am not sure in the moment, how to proceed with this project. Shall I ...
> > 1. Stay with TioPort, and have SWT as a subproject?
> > 2. make a project "Dejavu", that maintains all java derived sources and
> > also D libs building on top of this code?
> > 3. make a "SWT" (or use DWT?) project that only is for SWT?
> 
> Since other ports would probably depend on dejavu, it might make sense to keep that as part of the tioport project.  I guess you could create an 'swt' or 'dswt' project if you like, for separating the swt port from the rest.  The only strong opinion I have is that it shouldn't replace dwt, since it does things in a different way.

> Sorry about my ignorance, but I thought that Java SWT in general heavily depends on utils.collection and dejavu collection classes are just a thin wrapper using the Tango collection implementation ? Well, have to study the sources... However, regarding the *blinking* hint; Will you give me some support ?

Sure, you will get my support :)
I very much appreciate contributors.

Frank Benoit schrieb:
> Probably the char[] vs. String issue will go away.
> I am working on it.

With revision 324 it went away. Actually the SWT has helper methods for
all public methods, that contain an String and/or array argument and/or
return value.
Those are marked with the starting "dh_" name, which stands for "D Helper".

example: Button has now
void setText( String str );
void dh_setText( char[] str );

Frank Benoit wrote:

> Frank Benoit schrieb:
>> Probably the char[] vs. String issue will go away.
>> I am working on it.
> 
> With revision 324 it went away. Actually the SWT has helper methods for
> all public methods, that contain an String and/or array argument and/or
> return value.
> Those are marked with the starting "dh_" name, which stands for "D
> Helper".
> 
> example: Button has now
> void setText( String str );
> void dh_setText( char[] str );

hmmm... underscore in API methods is a bit ugly...

Isn't it possible to make it in oposite way, so that original methods will be prefixed and D Api will be clean?

Probably for original methods you could use prefix: 'swt'

e.g.
SwtSetText(String str); (Probably nicer - it is possible that someone will
want to use also this signature)
or
swt_setText(String str);

and provide overloaded D methods:
void setText( char[] str );
void setText( wchar[] str );
void setText( dchar[] str );
void setText( String str ); //I mean here string from Tango. Maybe it usable
in this context?


-- 
Regards
Marcin Kuszczak (Aarti_pl)
-------------------------------------
Ask me why I believe in Jesus - http://zapytaj.dlajezusa.pl (en/pl)
Doost (port of few Boost libraries) - http://www.dsource.org/projects/doost/
-------------------------------------

Marcin Kuszczak wrote:

> and provide overloaded D methods:
> void setText( char[] str );
> void setText( wchar[] str );
> void setText( dchar[] str );
> void setText( String str ); //I mean here string from Tango. Maybe it
> usable in this context?

BTW necessity for three overloaded methods for methods getting string in D is a reason why I would be happy to see one canonical String class for D, which would encapsulate these three types of arrays.

For me below implementation is close to perfect. Only problem is that it reduces maximal length of string.

http://www.dprogramming.com/dstring.php

-- 
Regards
Marcin Kuszczak (Aarti_pl)
-------------------------------------
Ask me why I believe in Jesus - http://zapytaj.dlajezusa.pl (en/pl)
Doost (port of few Boost libraries) - http://www.dsource.org/projects/doost/
-------------------------------------

> Isn't it possible to make it in oposite way, so that original methods will be prefixed and D Api will be clean?

hm, good point.

> and provide overloaded D methods:
> void setText( char[] str );
> void setText( wchar[] str );
> void setText( dchar[] str );
> void setText( String str ); //I mean here string from Tango. Maybe it usable
> in this context?

* in this case setText( "hello" ) will generate a conflict and you need
to write setText( "hello"c ). This is also ugly.
* What to do, if it is the return value? I cannot provide several
methods with only the return value changed.
* What to do, if there are more arguments. Shall i generate every
variation? I think there should be only one D-friendly argument replacement.

Actually I think about this:
change the Java char in D from wchar to jchar as a new type:

typedef wchar jchar;

void setValue( String str );
void setValue( jchar[] val );
void setValue( char[] str ); //Now, its not a conflict

But, what to do with return values?
String getValue();
char[] getValue(); // conflict

I would suggest using templates. Below (attachment) you can find test file
using templates.

Frank Benoit wrote:
> * in this case setText( "hello" ) will generate a conflict and you need
> to write setText( "hello"c ). This is also ugly.

See below example.

> * What to do, if it is the return value? I cannot provide several methods with only the return value changed.

See below example.

> * What to do, if there are more arguments. Shall i generate every variation? I think there should be only one D-friendly argument replacement.

I would make just one signature for every array type. It is natural and with templates - no problem.

void set(char[] a, char[] b, char[] c); // yes
void set(wchar[] a, wchar[] b, wchar[] c); // yes
void set(dchar[] a, dchar[] b, dchar[] c); // yes

//no - and also no for other combinations
void set(char[] a, wchar[] b, dchar[] c);


-- 
Regards
Marcin Kuszczak (Aarti_pl)
-------------------------------------
Ask me why I believe in Jesus - http://zapytaj.dlajezusa.pl (en/pl)
Doost (port of few Boost libraries) - http://www.dsource.org/projects/doost/
-------------------------------------

Just a few additional remarks and wishes for future DMD implementations:

1. With templates there is one drawback: as I know template methods can not be virtual. Maybe they could be in future?

2. I had to use "static if" because with IFTI method overloading doesn't work. IMHO should be cleaned in compiler implementation.

3. IMHO there should be no difference between normal functions and template functions, so normal functions could be also overloaded by return type. Also there would be no problems like in http://d.puremagic.com/issues/show_bug.cgi?id=798

I hope Walter some day will find a little bit time to fix these issues :-)

-- 
Regards
Marcin Kuszczak (Aarti_pl)
-------------------------------------
Ask me why I believe in Jesus - http://zapytaj.dlajezusa.pl (en/pl)
Doost (port of few Boost libraries) - http://www.dsource.org/projects/doost/
-------------------------------------

Marcin Kuszczak schrieb:
> Just a few additional remarks and wishes for future DMD implementations:
> 
> 1. With templates there is one drawback: as I know template methods can not be virtual. Maybe they could be in future?

This is a problem for the automated generation of these helper methods, they must be available in interface and certainly they need to be virtual.

I personally don't like to write getValue!(char)() to define the return
type. If the return type is Control[], the ported method looks like this:

JArrayJObject getControls();

The D help method has return type Control[]
Control[]     getControls(); // conflict

IMHO, this template solution is not complete.