digitalmars.D.dwt - next version of DWT?
- Frank Benoit (2/2) Apr 27 2007 There is this new port of SWT existing in the tioport project.
- bobef (2/4) Apr 27 2007
- Frank Benoit (4/6) Apr 28 2007 Shall SWT be moved to the DWT project?
- bobef (7/14) Apr 28 2007 I think SWT should not be called DWT, because this way you can just copy...
- BLS (5/7) Apr 27 2007 Of course.
- Frank Benoit (3/7) Apr 28 2007 The ported SWT sources do not depend on tango. Only dejavu does.
- BLS (Trutz Blanke Hans) (6/15) Apr 28 2007 Sorry about my ignorance, but I thought that Java SWT in general heavily...
- Frank Benoit (2/4) Apr 28 2007 Sure, you will get my support :)
- torhu (14/16) Apr 27 2007 Do you mean to actually call it DWT, and do s/SWT/DWT/g on the source?
- John Reimer (3/22) Apr 27 2007 I agree that a D.gui newsgroup would probably be best.
- Frank Benoit (10/23) Apr 28 2007 Yes, the pure name is not really an advantage.
- torhu (6/18) Apr 28 2007 Since other ports would probably depend on dejavu, it might make sense
- BLS (Trutz Blanke Hans) (3/22) Apr 28 2007 Hi, just think that instead of using dswt SWT/D is more significant.
- Frank Benoit (8/10) Apr 28 2007 With revision 324 it went away. Actually the SWT has helper methods for
- Marcin Kuszczak (23/36) Apr 29 2007 hmmm... underscore in API methods is a bit ugly...
- Marcin Kuszczak (14/20) Apr 29 2007 BTW necessity for three overloaded methods for methods getting string in...
- Chris Miller (7/10) Apr 29 2007 Is this limitation really a problem for some of your code? I thought it ...
- Marcin Kuszczak (76/81) May 06 2007 I did not get to this problem, mainly because I didn't used it. And I di...
- Chris Miller (23/55) May 13 2007 I forgot to reply to this; comments embedded...
- Marcin Kuszczak (30/59) May 14 2007 Hmmm... I have not clear feeling about that after your explanation...
- Frank Benoit (16/24) Apr 29 2007 * in this case setText( "hello" ) will generate a conflict and you need
- Marcin Kuszczak (19/26) Apr 29 2007 I would suggest using templates. Below (attachment) you can find test fi...
- Marcin Kuszczak (17/17) Apr 29 2007 Just a few additional remarks and wishes for future DMD implementations:
- Frank Benoit (9/13) Apr 29 2007 This is a problem for the automated generation of these helper methods,
- Marcin Kuszczak (20/38) Apr 29 2007 Yes, it can be real problem. Probably only Walter can help here :-) I re...
- Frank Benoit (19/56) Apr 29 2007 AFAIK the vtbl needs to be known at compile time. if the SWT class is
- Marcin Kuszczak (32/39) Apr 29 2007 I just have strong feeling that having good D-ish API for any ported fro...
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
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
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
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
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
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. BjoernThe 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
Frank Benoit Wrote: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 ? BjoernOf 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. BjoernThe 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
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
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
On Fri, 27 Apr 2007 19:24:42 +0200, torhu wrote:Frank Benoit wrote:I agree that a D.gui newsgroup would probably be best. -JJRThere 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
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
Frank Benoit wrote: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.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?
Apr 28 2007
Hi, just think that instead of using dswt SWT/D is more significant. Trutz Bla torhu Wrote:Frank Benoit wrote: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.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?
Apr 28 2007
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
Frank Benoit wrote:Frank Benoit schrieb: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/ -------------------------------------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 29 2007
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
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.phpIs 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
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
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: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.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?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
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.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/ -------------------------------------5. It's not standard (not included in Phobos nor in Tango)Agreed; I don't even use dstring at the moment.
May 14 2007
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
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
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
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
Frank Benoit wrote:Marcin Kuszczak schrieb: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.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.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(); // conflictWhen 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
Marcin Kuszczak schrieb:Frank Benoit wrote: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.Marcin Kuszczak schrieb: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.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.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 ambigiousI 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.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_' ? :)If the return type is Control[], the ported method looks like this: JArrayJObject getControls(); The D help method has return type Control[] Control[] getControls(); // conflictWhen you could change: JArrayJObject getControls(); into: JArrayJObject swtGetControls(); there would be no conflict with: Control[] getControls();
Apr 29 2007
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