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/
-------------------------------------

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_' ? :)

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/
-------------------------------------

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).

import std.stdio;
import std.c.stdlib;
import std.date;

import dstring;

void main() {

	//1
	string s = "test"c;
	string s1 = "test1"d;

	//2
	//s = "test2"c;

	//3
	s = s1;

	//4
	//char[] d = s;

	//5
	s~=s1;

	d_time starttime = getUTCtime();
	for(int i; i<1_000_000;i++) {
		string s2 = "test3"c;
	}
	d_time elapsedtime = getUTCtime() - starttime;
	writefln(elapsedtime);
}

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.

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/
-------------------------------------