View mode: basic / threaded / horizontal-split · Log in · Help
September 30, 2006
toString issue
As a result of the discussion about char[] above I have been converting 
some of my code from dchar[] to char[], but that reminded me of an issue 
i have with the current state of phobos. in object their is the method 
toString that happened to have the same name as the COMMONLY used 
function std.string.toString this causes objects toString to shadow 
std.strings to string inside class methods. I know that FQN can be used 
as a workaround but it makes the code unnecessary hard to read and I 
think that name clashes such as this should be avoided in the standard 
library.

PROPOSAL. change all methods in object to have some prefix for to string 
I suggest opString as the op prefix is already in use.
September 30, 2006
Re: toString issue
Johan Granberg wrote:
> PROPOSAL. change all methods in object to have some prefix for to string
> I suggest opString as the op prefix is already in use.

I agree, and the same about toHash. Naming consistency is the right thing.
September 30, 2006
Re: toString issue
Vladimir Kulev wrote:
> Johan Granberg wrote:
>> PROPOSAL. change all methods in object to have some prefix for to string
>> I suggest opString as the op prefix is already in use.
> 
> I agree, and the same about toHash. Naming consistency is the right thing.

I totally disagree, what consistency are you talking about?
toString and toHash are *not* operators, so prefixing them with op is 
misleading and inconsistent.
September 30, 2006
Re: toString issue
Hasan Aljudy wrote:
> 
> 
> Vladimir Kulev wrote:
>> Johan Granberg wrote:
>>> PROPOSAL. change all methods in object to have some prefix for to string
>>> I suggest opString as the op prefix is already in use.
>>
>> I agree, and the same about toHash. Naming consistency is the right 
>> thing.
> 
> I totally disagree, what consistency are you talking about?
> toString and toHash are *not* operators, so prefixing them with op is 
> misleading and inconsistent.

The prefix is not important the name collision issue is. The problem is 
that two commonly used identifiers collide and the use of an op prefix 
is one way to solve that (and would open up fore making them operator if 
desired at some later time)
September 30, 2006
Re: toString issue
Hasan Aljudy wrote:
> I totally disagree, what consistency are you talking about?
> toString and toHash are *not* operators, so prefixing them with op is
> misleading and inconsistent.

This methods are implied for all objects, so you can use them as well as
other unary operators like ~, excepting there are no special symbols for
them.

Anyway, Object.toString and std.string.toString collision should be
resolved, and renaming second one is also suitable for me.
September 30, 2006
Re: toString issue
Johan Granberg wrote:
> As a result of the discussion about char[] above I have been converting 
> some of my code from dchar[] to char[], but that reminded me of an issue 
> i have with the current state of phobos. in object their is the method 
> toString that happened to have the same name as the COMMONLY used 
> function std.string.toString this causes objects toString to shadow 
> std.strings to string inside class methods. I know that FQN can be used 
> as a workaround but it makes the code unnecessary hard to read and I 
> think that name clashes such as this should be avoided in the standard 
> library.
> 
> PROPOSAL. change all methods in object to have some prefix for to string 
> I suggest opString as the op prefix is already in use.

How about toUtf8() for classes and structs :-)


Sean
September 30, 2006
Re: toString issue
Sean Kelly wrote:
> Johan Granberg wrote:
> 
>> As a result of the discussion about char[] above I have been 
>> converting some of my code from dchar[] to char[], but that reminded 
>> me of an issue i have with the current state of phobos. in object 
>> their is the method toString that happened to have the same name as 
>> the COMMONLY used function std.string.toString this causes objects 
>> toString to shadow std.strings to string inside class methods. I know 
>> that FQN can be used as a workaround but it makes the code unnecessary 
>> hard to read and I think that name clashes such as this should be 
>> avoided in the standard library.
>>
>> PROPOSAL. change all methods in object to have some prefix for to 
>> string I suggest opString as the op prefix is already in use.
> 
> 
> How about toUtf8() for classes and structs :-)
> 
> 
> Sean

Gets my vote.  Note that Mango classes typically already do this (with toString just 
calling toUtf8 in most cases), and provide toUtf16/toUtf32 counterparts.  It is indeed 
effective.  :)

-- Chris Nicholson-Sauls
October 01, 2006
Re: toString issue
Gets my vote too , it's also more descriptive than 'toString' .

Chris Nicholson-Sauls wrote:
> Sean Kelly wrote:
>> Johan Granberg wrote:
>>
>>> As a result of the discussion about char[] above I have been 
>>> converting some of my code from dchar[] to char[], but that reminded 
>>> me of an issue i have with the current state of phobos. in object 
>>> their is the method toString that happened to have the same name as 
>>> the COMMONLY used function std.string.toString this causes objects 
>>> toString to shadow std.strings to string inside class methods. I know 
>>> that FQN can be used as a workaround but it makes the code 
>>> unnecessary hard to read and I think that name clashes such as this 
>>> should be avoided in the standard library.
>>>
>>> PROPOSAL. change all methods in object to have some prefix for to 
>>> string I suggest opString as the op prefix is already in use.
>>
>>
>> How about toUtf8() for classes and structs :-)
>>
>>
>> Sean
> 
> Gets my vote.  Note that Mango classes typically already do this (with 
> toString just calling toUtf8 in most cases), and provide toUtf16/toUtf32 
> counterparts.  It is indeed effective.  :)
> 
> -- Chris Nicholson-Sauls
October 02, 2006
Re: toString issue
Sean Kelly wrote:
> 
> How about toUtf8() for classes and structs :-)
> 
> 
> Sean

I think there's a fundamental problem with the way D deals with strings.
The spec claims that D natively supports strings through char[], at the 
same time, claims that D fully supports Unicode.
The fundamental issue is that UTF-8 is one encoding for Unicode strings, 
but it's not always the best choice. Phobos mostly only deals with 
char[], and mixing code that uses wchar[] with code that uses char[] 
isn't very straight forward.

Consider the simple case of reading a text file and detecting "words". 
To detect a word, you must first recognize letters, no .. not English 
letters; letters of any language, and for that purpose, we have 
isUniAlpha function. Now, If you encode the string as char[], then how 
are you gonna determine whether or not the next character is a Unicode 
alpha or not?

The following definitely shouldn't work:
//assuming text is char[]
for( int i = 0; i < text.length; i++ )
{
    bool isLetter = isUniAlpha( text[i] );
    ....
}

because isUniAlpha takes a dchar parameter, and of course, because a 
single char doesn't necessarily encode a Unicode character just by 
itself; if you're dealing with non-English text, then most likely a 
single char will only hold half the encoding for that letter.
Surprisingly, the compiler allows this kind of code, but that's not the 
point. The point is, this code will never work, because char[] is not a 
very good way to hold a Unicode string.
Of course there are ways around this, but they are still just "workarounds".

Should you choose wchar[] (or dchar[]) to represent strings, you will 
get into all kinds of troubles dealing with phobos. The standard library 
always deals with strings using char[], this includes std.string and 
std.regexp, and even the Exception class. So, if you're using wchar[] to 
represent strings, and you want to throw an exception, you can't just say:
# throw new Exception( myString );
because the compiler will complain (can't cast wchar[] to char[]), so 
you'll need toUtf8( myString ), and you're code can quickly become full 
of calls to toUtf* functions.

Personally, I think D needs a proper String class built into the 
language and the standard library.

or at least, casting between the different encodings should be seamless 
to the coder; just let the compiler call the appropriate toUtf* function 
 and allow implicit casting.
October 02, 2006
Re: toString issue
On Mon, 02 Oct 2006 00:52:44 -0600, Hasan Aljudy wrote:

> Sean Kelly wrote:
>> 
>> How about toUtf8() for classes and structs :-)
>> 
>> Sean
> 
> I think there's a fundamental problem with the way D deals with strings.
> The spec claims that D natively supports strings through char[], at the 
> same time, claims that D fully supports Unicode.
> The fundamental issue is that UTF-8 is one encoding for Unicode strings, 
> but it's not always the best choice. Phobos mostly only deals with 
> char[], and mixing code that uses wchar[] with code that uses char[] 
> isn't very straight forward.
> 
> Consider the simple case of reading a text file and detecting "words". 
> To detect a word, you must first recognize letters, no .. not English 
> letters; letters of any language, and for that purpose, we have 
> isUniAlpha function. Now, If you encode the string as char[], then how 
> are you gonna determine whether or not the next character is a Unicode 
> alpha or not?
> 
> The following definitely shouldn't work:
> //assuming text is char[]
> for( int i = 0; i < text.length; i++ )
> {
>      bool isLetter = isUniAlpha( text[i] );
>      ....
> }

 foreach(int i, dchar c; text)
 {
      bool isLetter = isUniAlpha( c );
      ...
 }


-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
2/10/2006 5:10:26 PM
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home