"nick" <nick.atamas@gmail.com> wrote in message news:dri35u$1o0f$1@digitaldaemon.com...
> Walter Bright wrote:
>
>> It's a good question. I'll reply here in general, the specifics for complex numbers I gave a link to in the other message.
>>
>> So, practically, one is stuck with not allowing user defined tokens or user defined syntax. Unfortunately, then one must give up hope of *seamlessly* integrating new types into the language via libraries, as C++'s <complex> demonstrates.
> But D's operator overloading allows for *almost* seamlessly integrating math types into the language. Right?

Yes. But I would never suggest replacing the 'int' type with a class, and I've never heard even the die hard C++ "do it all in the library" people suggest going that far.

>  > As an aside - do we *really* need strings to be a user defined type? I
>> believe the C++ experience with that shows it to be a disaster. I can expound on that in detail if anyone cares <g>.
> I have experienced a bit of unpleasantness with C++ strings, including a
> nontrivial variant of this:
> printf("Hello, %s", std::string("World")); //No c_str() -> SegFault;
>
> I would certainly like to hear the details.

The big problem is everyone produces their own string package. This means that 3rd party libraries can't interoperate with each other - each is its own, incompatible ecosystem. The answer I hear from that is to standardize std::string. Ok, but then one is stuck with the inflexibility of a core string type with the clumsiness of a library string type - the worst of both worlds.

For some more thoughts on this, see www.digitalmars.com/d/cppstrings.html.

The lack of decent built in strings has been a serious problem for C++ since the beginning. With core strings that work, then 3rd party libraries won't bother inventing their own, and they can pass strings between each other as easilly as ints.

>> Guy Steele says that few C++ users use imaginary and complex numbers. True. But I attribute that to the poor support for such in C++, which is why numeric programmers tend to stick with FORTRAN. The C and C++ committees and compiler vendors have historically neglected the interests of numeric programmers. (For example, look at the abandonment of 80 bit reals! Incredible.)
> Well, I thought Steele's point was more along the lines of "Java needs operator overloading", and complex numbers was just an example targeted at his audience. The link you sent me removed all doubt.
>
> The 80bit float issue is ridiculous, of course; especially because 80 bit floats are supported by both AMD and Intel.

Dropping support for it astounded me.

Walter Bright wrote:
> "nick" <nick.atamas@gmail.com> wrote in message news:dri35u$1o0f$1@digitaldaemon.com...
> 
>>Walter Bright wrote:
>>
>>
>>> [snip]
>>
>>I have experienced a bit of unpleasantness with C++ strings, including a nontrivial variant of this:
>>printf("Hello, %s", std::string("World")); //No c_str() -> SegFault;
>>
>>I would certainly like to hear the details.
> 
> 
> The big problem is everyone produces their own string package. This means that 3rd party libraries can't interoperate with each other - each is its own, incompatible ecosystem. The answer I hear from that is to standardize std::string. Ok, but then one is stuck with the inflexibility of a core string type with the clumsiness of a library string type - the worst of both worlds.
> 
> For some more thoughts on this, see www.digitalmars.com/d/cppstrings.html.
> 
> The lack of decent built in strings has been a serious problem for C++ since the beginning. With core strings that work, then 3rd party libraries won't bother inventing their own, and they can pass strings between each other as easilly as ints.
> 

But then, doesn't this mean that D should have a standard String class too? just like Java?
I mean, think about java, how silly would it be for someone to invent their own String class? really silly I'd say.
But for D, I think there are good reasons for inventing one's own string class:
- True OOP tends to never use arrays, always use objects, (strings, collections .. etc). You may disagree with them, but the fact is there are people who would go about wrapping wchar[] in a class. For instance, I know one of my professors who would do that (if he ever used D). Frankly, he's the one who made me hate C++, and that's pretty much the reason why I decided to start using D.
When I told him about D, he said that he didn't look deeply into it, but he noticed that alot of the "features" (he put it in quotes) use completely procedural constructs (i.e. arrays); I'm under the impressions that if the language doesn't provide enough OO support, he won't use it. (If he ever had to use D, he would probably invent a String class!)
And guess what, if that's his opinion, it's probably the opinion of many others.
So please, for the sake of attracting these people to D, let D have a standard String class!!!


- Another thing is dealing with char, wchar, dchar inconsistencies? (sorry, I don't know much about that, but I assume there will be some conflicts if I use wchar[] and someone else uses dchar[] somewhere else).

Hasan Aljudy wrote:
>
> When I told him about D, he said that he didn't look deeply into it, but he noticed that alot of the "features" (he put it in quotes) use completely procedural constructs (i.e. arrays);

Ironically, the C++ standard library is designed to encourage the use of procedural constructs over OO ones.

> I'm under the
> impressions that if the language doesn't provide enough OO support, he won't use it. (If he ever had to use D, he would probably invent a String class!)
> And guess what, if that's his opinion, it's probably the opinion of many others.

I'm sure it is.  So what would you suggest?  As a fan of the procedural/C++ style I can't really conceive a design I find acceptable.  I'd much rather do everything via free functions (and that nifty trick that allows free functions to pretend they're member functions when used with arrays).

> - Another thing is dealing with char, wchar, dchar inconsistencies? (sorry, I don't know much about that, but I assume there will be some conflicts if I use wchar[] and someone else uses dchar[] somewhere else).

Explicit conversion is required, but that's it.


Sean

Hasan Aljudy wrote:
> But then, doesn't this mean that D should have a standard String class too? just like Java?
>
> [..SNIP..]
> 
> - Another thing is dealing with char, wchar, dchar inconsistencies? (sorry, I don't know much about that, but I assume there will be some conflicts if I use wchar[] and someone else uses dchar[] somewhere else).

You are right, a lot of people would not like /char[]/.
I think the real reason they won't like it is because /char[]/ is because they like to see the word STRING and be reassured as to the purpose of an entity; the same logic applies to having a /bool/ instead of /int/.

With that said, I can't think of too many instances where people would be thoroughly confused by this because an array of characters is USUALLY a string unless it's an array of bytes. However, since D has a type /byte/ it shouldn't be a problem.

Finally, I think that string and/or String should be aliased to char[] to prevent people from writing their own classes.

nick wrote:
> Hasan Aljudy wrote:
>> But then, doesn't this mean that D should have a standard String class too? just like Java?
>  >
>> [..SNIP..]
>>
>> - Another thing is dealing with char, wchar, dchar inconsistencies? (sorry, I don't know much about that, but I assume there will be some conflicts if I use wchar[] and someone else uses dchar[] somewhere else).
> 
> You are right, a lot of people would not like /char[]/.
> I think the real reason they won't like it is because /char[]/ is because they like to see the word STRING and be reassured as to the purpose of an entity; the same logic applies to having a /bool/ instead of /int/.
> 
> With that said, I can't think of too many instances where people would be thoroughly confused by this because an array of characters is USUALLY a string unless it's an array of bytes. However, since D has a type /byte/ it shouldn't be a problem.
> 
> Finally, I think that string and/or String should be aliased to char[] to prevent people from writing their own classes.

This might be the best approach.  Simply add these aliases:

alias char[]  string;
alias wchar[] wstring;
alias dchar[] dstring;

and then implement the rest as free functions (which, as I mentioned in my other post, can be called as if they were member functions in D). This would give D a string "class" of sorts, though it would not be inheritable.


Sean

Could you explain the concept of a free function?

nick wrote:
> Could you explain the concept of a free function?

For whatever reason, DMD makes this possible:

char[] str;

// this is a "free function"
int toInteger( char[] s ) { ... }

int i = toInteger( str ),
    j = str.toInteger();

Both of the above calling conventions work for arrays (though not for primitives).


By "free function" I merely meant a function that is declared at global scope.


Sean

Sean Kelly wrote:
> nick wrote:
>> Could you explain the concept of a free function?
> 
> For whatever reason, DMD makes this possible:
> 
> char[] str;
> 
> // this is a "free function"
> int toInteger( char[] s ) { ... }
> 
> int i = toInteger( str ),
>     j = str.toInteger();
> 
> Both of the above calling conventions work for arrays (though not for primitives).
> 
> 
> By "free function" I merely meant a function that is declared at global scope.
> 
> 
> Sean
Oh. Right. Actually that makes perfect sense to me.
My understanding is that this comes directly from how classes are implemented (/this/ gets passed in as the first parameter).

I could be totally wrong though.

nick wrote:
> Sean Kelly wrote:
>> nick wrote:
>>> Could you explain the concept of a free function?
>>
>> For whatever reason, DMD makes this possible:
>>
>> char[] str;
>>
>> // this is a "free function"
>> int toInteger( char[] s ) { ... }
>>
>> int i = toInteger( str ),
>>     j = str.toInteger();
>>
>> Both of the above calling conventions work for arrays (though not for primitives).
>>
>>
>> By "free function" I merely meant a function that is declared at global scope.
>>
> Oh. Right. Actually that makes perfect sense to me.
> My understanding is that this comes directly from how classes are implemented (/this/ gets passed in as the first parameter).
> 
> I could be totally wrong though.

I think you're right.  Though I don't understand why this wouldn't extend to primitives as well.


Sean

In article <drjodu$18oc$1@digitaldaemon.com>, Sean Kelly says...
>
>nick wrote:
>> Sean Kelly wrote:
>>> nick wrote:
>>>> Could you explain the concept of a free function?
>>>
>>> For whatever reason, DMD makes this possible:
>>>
>>> char[] str;
>>>
>>> // this is a "free function"
>>> int toInteger( char[] s ) { ... }
>>>
>>> int i = toInteger( str ),
>>>     j = str.toInteger();
>>>
>>> Both of the above calling conventions work for arrays (though not for primitives).
>>>
>>>
>>> By "free function" I merely meant a function that is declared at global scope.
>>>
>> Oh. Right. Actually that makes perfect sense to me.
>> My understanding is that this comes directly from how classes are
>> implemented (/this/ gets passed in as the first parameter).
>> 
>> I could be totally wrong though.
>
>I think you're right.  Though I don't understand why this wouldn't extend to primitives as well.
>

The transformation is done in expression.c:

Expression *CallExp::semantic(Scope *sc)

I doesn't look like there is any reason this can't be done with primitives either.

I think it would be great if we could write functions that would then be called as a 'property' for primitives. For example, what we can do now with strings;

char[] lowercase(char[] str) {...}
char[] str = ...; str.lowercase();

One problem (inconsistency?) with that is currently 'str.lowercase()' has to be
called with the parantheses, so doesn't have property or 'field' like syntax.

>
>Sean