www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.dwt - next version of DWT?

reply Frank Benoit <keinfarbton googlemail.com> writes:
There is this new port of SWT existing in the tioport project.
Would it be appreciated to make it the next version of DWT?
Apr 27 2007
next sibling parent reply bobef <asd asd.asd> writes:
Could you please explain what you mean by "Would it be appreciated to make it
the next version of DWT?" ? Sorry for my poor English.

Frank Benoit Wrote:

 There is this new port of SWT existing in the tioport project.
 Would it be appreciated to make it the next version of DWT?

Apr 27 2007
parent reply Frank Benoit <keinfarbton googlemail.com> writes:
bobef schrieb:
 Could you please explain what you mean by "Would it be appreciated to 
 make it the next version of DWT?" ?

Shall SWT be moved to the DWT project? Shall it be called DWT? Shall it be the successor of the current DWT version?
Apr 28 2007
parent bobef <adas adasd.asdasd> writes:
I think SWT should not be called DWT, because this way you can just copy/paste
java code and don't have to replace SWT with DWT.

I think it will be a good idea to make it more D oriented like DWT. I.e. char[]
instead of String and

widget.handleEvent(data,delegate(Event e){
//this saves a lot of time and space
});

I still can't understand the rest of the question. Who cares if it is called
DWT or SWT or where the project is placed if the port is more up to date and
more usable than DWT? Oh and.... import dwt.all is nice too. It sucks if you
have to import 20 lines with org.eclipse.blah.blah.200.characters... You got
the point :)

Frank Benoit Wrote:

 bobef schrieb:
 Could you please explain what you mean by "Would it be appreciated to 
 make it the next version of DWT?" ?

Shall SWT be moved to the DWT project? Shall it be called DWT? Shall it be the successor of the current DWT version?

Apr 28 2007
prev sibling next sibling parent reply BLS <nanali nospam-wanadoo.fr> writes:
Frank Benoit Wrote:

 There is this new port of SWT existing in the tioport project.
 Would it be appreciated to make it the next version of DWT?

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
Apr 27 2007
parent reply Frank Benoit <keinfarbton googlemail.com> writes:
 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*
Apr 28 2007
parent reply BLS (Trutz Blanke Hans) <nanali nospam-wanadoo.fr> writes:
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
Apr 28 2007
parent Frank Benoit <keinfarbton googlemail.com> writes:
 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.
Apr 28 2007
prev sibling parent reply torhu <fake address.dude> writes:
Frank Benoit wrote:
 There is this new port of SWT existing in the tioport project.
 Would it be appreciated to make it the next version of DWT?

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. To name some differences: DWT uses char[] instead of String, supports delegates in some places, and it uses Phobos instead of Tango. It also uses the 'import dwt.all;' idiom, which tioport doesn't. I'm not saying that I want an swt.all module, by all means, and my own DWT project is already ported to tioport SWT. Since DWT seems to be a dead project, I think that it's okay for SWT to use this newsgroup. Or even better, if Walter would create a d.D.gui newsgroup. :)
Apr 27 2007
next sibling parent John Reimer <terminal.node gmail.com> writes:
On Fri, 27 Apr 2007 19:24:42 +0200, torhu wrote:

 Frank Benoit wrote:
 There is this new port of SWT existing in the tioport project.
 Would it be appreciated to make it the next version of DWT?

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. To name some differences: DWT uses char[] instead of String, supports delegates in some places, and it uses Phobos instead of Tango. It also uses the 'import dwt.all;' idiom, which tioport doesn't. I'm not saying that I want an swt.all module, by all means, and my own DWT project is already ported to tioport SWT. Since DWT seems to be a dead project, I think that it's okay for SWT to use this newsgroup. Or even better, if Walter would create a d.D.gui newsgroup. :)

I agree that a D.gui newsgroup would probably be best. -JJR
Apr 27 2007
prev sibling parent reply Frank Benoit <keinfarbton googlemail.com> writes:
 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? This is why I was posting this question.
 To name some differences:  DWT uses char[] instead of String, supports
 delegates in some places, and it uses Phobos instead of Tango.  It also
 uses the 'import dwt.all;' idiom, which tioport doesn't.  I'm not saying
 that I want an swt.all module, by all means, and my own DWT project is
 already ported to tioport SWT.

Probably the char[] vs. String issue will go away. I am working on it.
 Since DWT seems to be a dead project, I think that it's okay for SWT to
 use this newsgroup.  Or even better, if Walter would create a d.D.gui
 newsgroup. :)

renaming the newsgroup makes sense. I second that.
Apr 28 2007
next sibling parent reply torhu <fake address.dude> writes:
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.
Apr 28 2007
parent BLS (Trutz Blanke Hans) <nanali nospam-wanadoo.fr> writes:
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.

Apr 28 2007
prev sibling parent reply Frank Benoit <keinfarbton googlemail.com> writes:
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 );
Apr 28 2007
parent reply Marcin Kuszczak <aarti interia.pl> writes:
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/ -------------------------------------
Apr 29 2007
next sibling parent reply Marcin Kuszczak <aarti interia.pl> writes:
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/ -------------------------------------
Apr 29 2007
parent reply "Chris Miller" <chris dprogramming.com> writes:
On Sun, 29 Apr 2007 04:34:08 -0400, Marcin Kuszczak <aarti interia.pl>  
wrote:

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

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

Is this limitation really a problem for some of your code? I thought it was still big enough, with room to spare. I don't recall ever having a string of over 1_073_741_824 characters. Also, for a 64-bit program, the limit is raised considerably, to thousands of terabytes (and string.MAX_LENGTH will reflect this automatically).
Apr 29 2007
parent reply Marcin Kuszczak <aarti interia.pl> writes:
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Chris Miller wrote:
 Is this limitation really a problem for some of your code? I thought it
 was still big enough, with room to spare. I don't recall ever having a
 string of over 1_073_741_824 characters. Also, for a 64-bit program, the
 limit is raised considerably, to thousands of terabytes (and
 string.MAX_LENGTH will reflect this automatically).

I did not get to this problem, mainly because I didn't used it. And I did not used it because your work still doesn't meet my criteria for something what I would use in my development: 1. Because there will be *for sure* people who will get to this limit. If something can happen it will happen. And then you are in trouble, because you can no more easily interchange between your string class and d character arrays, and your are in the start point again... In fact when assigning *any* char[] variable to your string, I should first check if it will fit into it... 2. I want string to do more than just normal character arrays, and I shouldn't accept something what is in some areas better, but in some worse. Higher abstraction has usually drawbacks - it needs more processing power and/or more memory. But I accept it as I need higher abstraction... 3. Allocating one additional byte in your struct probably will not be a big deal for anyone...And it shouldn't break anything, should it? 4. There is still problem with optimization of memory consumption when adding dchar to string containing char[]. 4 times bigger memory consumption than original char[] is too much for me. I think that your string struct should be default optimize for lower memory consumption, and has static fields (methods) to set policy for speed. 5. It's not standard (not included in Phobos nor in Tango) When I answering your question I decided to quickly test two currently available string classes for D language: dstring and Tango String class. Below is quick comparison (It doesn't pretend to be exhaustive and/or very accurate): 1. Assigning: a. yes // string s = "Test"c; //this is cool! // string s1 = "Test1"d; b. yes // auto s = new String!(char)("Test"); // auto s1 = new String!(dchar)("Test"); 2. Assigning again literals: a. no // s = "Test1"c; //why? b. no // s = "test2"c; 3. Assigning variables a. yes // s = s1; b. no // s = s1; 4. Reading (d language shortcoming): a. no // char[] d = s; b. no // char[] d = s; 5. Concatenating a. yes // s~=s1; b. no // s!=s1; 6. Proper slicing of Utf8 sequence by letters not bytes a. yes b. ??? 7. Speed a. 147 ms// b. //I couldn't get StopWatch to work, but it seems that it was longer :-) Proper comparison would require more tests. These are just a few from top of my head... Test programs attached. Personally I think that that your implementation is more low level, but saying that I think much more usefull in general case. Tango implementation looks like advanced class for word-processors :-) I was disappointed seeing this kind of string in it... Comming from C++ world I would be happy to see string behaving similarly to STL string. This implementation should allow easy conversion between it and character arrays (also implicit - sth. like opImplicitCast what Andrei suggested on D NG) and also between character arrays and string (your implementation cover almost fully this case). I think that there is a place for both: templated methods taking arrays of characters when speed is necessary and string struct/class for cases where speed is not such a big concern. I am building library which will not demand speed and adding 3 versions of every function would be lot of work. Leaving only char[] versions would be also not good... In such a cases string struct/class should be taken into account... PS. Sorry for pointed-out-style of my e-mail. English is not my native language, and it is easier for me to write like this. And additionally I like such a style :-) But maybe someone can think that it's too simple way of talking... -- 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/ -------------------------------------
May 06 2007
parent reply "Chris Miller" <chris dprogramming.com> writes:
I forgot to reply to this; comments embedded...

On Sun, 06 May 2007 05:36:23 -0400, Marcin Kuszczak <aarti interia.pl>  
wrote:

 Chris Miller wrote:
 Is this limitation really a problem for some of your code? I thought it
 was still big enough, with room to spare. I don't recall ever having a
 string of over 1_073_741_824 characters. Also, for a 64-bit program, the
 limit is raised considerably, to thousands of terabytes (and
 string.MAX_LENGTH will reflect this automatically).

I did not get to this problem, mainly because I didn't used it. And I did not used it because your work still doesn't meet my criteria for something what I would use in my development: 1. Because there will be *for sure* people who will get to this limit. If something can happen it will happen. And then you are in trouble, because you can no more easily interchange between your string class and d character arrays, and your are in the start point again... In fact when assigning *any* char[] variable to your string, I should first check if it will fit into it...

Well, I just wasn't sure. I'm still wondering what others think about this limitation. I wrote dstring mainly to see how it would go. A billion characters seems plenty to me; and this is just for 32-bit binaries. I could be wrong. I also figured those who need incredibly large strings will probably want to write special-purpose string handling code anyway, and it would seem odd that they would pass such large strings to functions that don't expect them to be so large (e.g. std.string.replace on a 1.5 gig string? yikes). You don't need to check if it fits because it does that for you and throws an exception.
 2. I want string to do more than just normal character arrays, and I
 shouldn't accept something what is in some areas better, but in some  
 worse.
 Higher abstraction has usually drawbacks - it needs more processing power
 and/or more memory. But I accept it as I need higher abstraction...
 3. Allocating one additional byte in your struct probably will not be a  
 big
 deal for anyone...And it shouldn't break anything, should it?

8 bytes, nicely aligned struct, vs. 9 bytes? or maybe 12 bytes? It was designed to be easy to pass to functions and pack into other structures, like char[]. Adding to it will kill these benefits, especially the ability to return into registers.
 4. There is still problem with optimization of memory consumption when
 adding dchar to string containing char[]. 4 times bigger memory  
 consumption
 than original char[] is too much for me. I think that your string struct
 should be default optimize for lower memory consumption, and has static
 fields (methods) to set policy for speed.

Any dchar added to it doesn't do it; it will only if it can't fit into a single char or wchar. To get to dchar requires characters outside the BMP even, which can be quite rare. I believe Python is going to be using "dchar" for any Unicode strings beyond ASCII. I think dstring's way at least saves more than this.
 5. It's not standard (not included in Phobos nor in Tango)

Agreed; I don't even use dstring at the moment.
May 13 2007
parent Marcin Kuszczak <aarti interia.pl> writes:
Chris Miller wrote:

 Well, I just wasn't sure. I'm still wondering what others think about this
 limitation. I wrote dstring mainly to see how it would go.
 
 A billion characters seems plenty to me; and this is just for 32-bit
 binaries. I could be wrong. I also figured those who need incredibly large
 strings will probably want to write special-purpose string handling code
 anyway, and it would seem odd that they would pass such large strings to
 functions that don't expect them to be so large (e.g. std.string.replace
 on a 1.5 gig string? yikes).
 

Hmmm... I have not clear feeling about that after your explanation... Consider the fact that "mbox" e-mail storing files (having internally text format) can quite easily reach 1 GB... Probably it is not so rare... My "inbox" is about 180 Mb now, and in business environments there is much more emails in inboxes...
 You don't need to check if it fits because it does that for you and throws
 an exception.
 

This is good :-)
 8 bytes, nicely aligned struct, vs. 9 bytes? or maybe 12 bytes? It was
 designed to be easy to pass to functions and pack into other structures,
 like char[]. Adding to it will kill these benefits, especially the ability
 to return into registers.
 

4 bytes length + 4 bytes pointer? To say true I never use such low level programming and never care about that... There should really other people say something about this... What would be use case for such a feature? It would help me to understand your motivation...
 
 Any dchar added to it doesn't do it; it will only if it can't fit into a
 single char or wchar. To get to dchar requires characters outside the BMP
 even, which can be quite rare.

Good to know...
 
 I believe Python is going to be using "dchar" for any Unicode strings
 beyond ASCII. I think dstring's way at least saves more than this.
 
 5. It's not standard (not included in Phobos nor in Tango)

Agreed; I don't even use dstring at the moment.

Did you consider to post your implementation to Tango team? I think it would be really valuable to have it in Tango. I would say it should be on basic level (object.di ?). At least you could get feedback: why it doesn't fit in Tango. (I would be interested to know it also.) With possible future additions of opImplicitCast to D dstring could work nicely with all kinds of char arrays in both ways, so that you could send string to function which was written for char[] and have implicitly converted string to char[]. The same should happen in opposite way (char[] -> string). This way dstring could nicely integrate with types already available in D. I really don't feel much need for other solutions which doesn't help with hiding complexity of different character arrays... -- 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/ -------------------------------------
May 14 2007
prev sibling parent reply Frank Benoit <keinfarbton googlemail.com> writes:
 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
Apr 29 2007
parent reply Marcin Kuszczak <aarti interia.pl> writes:
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


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/ -------------------------------------
Apr 29 2007
parent reply Marcin Kuszczak <aarti interia.pl> writes:
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/
-------------------------------------
Apr 29 2007
parent reply Frank Benoit <keinfarbton googlemail.com> writes:
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.
Apr 29 2007
parent reply Marcin Kuszczak <aarti interia.pl> writes:
Frank Benoit wrote:

 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.

Yes, it can be real problem. Probably only Walter can help here :-) I really don't know what to do to make it work properly.
 I personally don't like to write getValue!(char)() to define the return
 type. 

This one I don't get. For char type you do not have to call template explicitly. Because of default template parameter of type 'char' you just call getValue(); and it is implicitly equivalent of getValue!(char)(); Please see my example for reference.
 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

When you could change: JArrayJObject getControls(); into: JArrayJObject swtGetControls(); there would be no conflict with: Control[] getControls();
 IMHO, this template solution is not complete.

-- 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/ -------------------------------------
Apr 29 2007
parent reply Frank Benoit <keinfarbton googlemail.com> writes:
Marcin Kuszczak schrieb:
 Frank Benoit wrote:
 
 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?

they must be available in interface and certainly they need to be virtual.

Yes, it can be real problem. Probably only Walter can help here :-) I really don't know what to do to make it work properly.

AFAIK the vtbl needs to be known at compile time. if the SWT class is compiled, it is not know what template argument will be applied by a user. This is, why a template member function cannot be virtual. So this is a blocker for using template members here. They cannot be used in interface or for abstract methods.
 
 I personally don't like to write getValue!(char)() to define the return
 type. 

This one I don't get. For char type you do not have to call template explicitly. Because of default template parameter of type 'char' you just call getValue(); and it is implicitly equivalent of getValue!(char)(); Please see my example for reference.

If you want to have the method name unchanged, you need to apply the template argument, to omit the conflict with the original method. (And i think a default argument in the template will also generate an error) JavaString getValue(); T[] getValue(T=char)(); calling getValue() is ambigious
 
 
 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

When you could change: JArrayJObject getControls(); into: JArrayJObject swtGetControls(); there would be no conflict with: Control[] getControls();

Now again we have to change the method name to make it unique :) I would prefer to let the original have the original name, and have the helper method have the changed name. And if it is needed for the return type, i would do it for all helpers. 'swt' is not working as a general 'escaping sequence' (porting other projects) How about 'dh_' ? :)
Apr 29 2007
parent Marcin Kuszczak <aarti interia.pl> writes:
Frank Benoit wrote:

 Now again we have to change the method name to make it unique :)
 I would prefer to let the original have the original name, and have the
 helper method have the changed name.
 And if it is needed for the return type, i would do it for all helpers.
 'swt' is not working as a general 'escaping sequence' (porting other
 projects)
 How about 'dh_' ? :)

I just have strong feeling that having good D-ish API for any ported from Java project is crucial to its wide adoption. So any solution which would allow this will be good. If methods with 'dh_' prefix will not be intended for use by library users, I don't care much about it. This prefix can stay, but API for users should be clean. (Maybe even this prefix should be longer to make sure that no collision will occur?) Because of problems with templates I have another proposition. It is consistent and should work good. For every method taking character arrays, define 3 methods with suffixes to their names: void set(char[] a, char[] b, char[] c); // empty suffix void setW(wchar[] a, wchar[] b, wchar[] c); // suffix "W" void setD(dchar[] a, dchar[] b, dchar[] c); // suffix "D" Same can be done for methods which returns different return types: char[] getText(); wchar[] getTextW(); dchar[] getTextD(); Please just do not make 'dh_' methods standard way of using SWT port by D users! I will not be able to answer your posts from now till Thursday evening because I am leaving for vacation. But I hope that I was a little bit helpful with my suggestions... I really appreciate your work on TioPort and SWT. Good luck! -- 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/ -------------------------------------
Apr 29 2007