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:
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:
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?


 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.


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