In article <d07f6a$3pt$1@digitaldaemon.com>, =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
>
>Mike Parker wrote:
>
>> I think the most important component to woo C++/Java developers is Phobos. I have spoken with people who have shown an interest in D, but without a standard library that offers what they have come to take for granted most of them are hesitant to take the plunge.
>> 
>> For the C++ types, I think an STL equivalent is the big thing. To this end, I really believe either DTL or MinTL needs to be integrated into core Phobos as part of a 1.0 release. This will make people in both camps happy (Java developers love their Collections).
>
>Forgive my ignorance, but wasn't both of STL and Collections added long after the initial releases of those two languages ?

True, but the fact is that it was 10 years ago.

Ciao

Regan Heath wrote:
> On Thu, 03 Mar 2005 23:28:20 +0100, Jan-Eric Duden <jeduden@whisset.com>  wrote:
> 
>> Walter wrote:
>>
>>> "Mike Parker" <aldacron71@yahoo.com> wrote in message
>>> news:d07dbj$24e$1@digitaldaemon.com...
>>>
>>>> For the C++ types, I think an STL equivalent is the big thing. To this
>>>> end, I really believe either DTL or MinTL needs to be integrated into
>>>> core Phobos as part of a 1.0 release. This will make people in both
>>>> camps happy (Java developers love their Collections).
>>>
>>>   I understand that, but a DTL is probably going to be a D 2.0 feature.  But
>>> part of the problem is a perception issue. D handles already, in the  core
>>> language, much of the functionality of STL. (For an example, see
>>> www.digitalmars.com/d/cppstrings.html) People briefly look at D, and  wonder
>>> where the 'string class' is. It takes a bit more in depth look at D to
>>> realize that a string class for D would be redundant, as would be vector
>>> classes, slice classes, for_each kludges, hash collections, etc. One  other
>>> large reason for the existence of STL is memory management. D does  automatic
>>> memory management.
>>>  DTL needs go at least one or two conceptual steps beyond STL, because D
>>> already handles much of the core point of STL.
>>>
>> On the other hand, you still want to provide a standard string class.
>>
>> 1. A string class comes handy with the methods like  toUpper,toLower,replaceChar,findNextToken and so on.
>> 2. A string class can abstract from the actual encoding UTF-8,  UTF-16,UTF-32 and can provide automatic conversions.
>> 3. It provides a consistent way to access functions that work on strings.
>>
>> There are probably more things that a string class could provide.
>> Some of the functions can be just global functions, but I think
>> a lot of people are used access them as methods.
>>
>> Here an example:
>>
>> D right now:
>>
>> char[] s;
>> s.length <- property
>> toUTF32(s) <- global function
>>
>> D with a standardized string class
>>
>> string s;
>>
>> s.length()  <- method
>> s.toUTF32() <- method
>>
>> This is much more consistent.
> 
> 
> You can already use the syntax above. D allows you to call a function  which takes an array as it's first parameter as if it was a  method/property of the array.
> 
> eg.
> 
> char[] s,p;
> p = s.toTUF32();
> 
>> Since strings are so fundamental, there should be a single standardized
>> string interface. It needs to be powerful enough so that there is no  reason for anyone to develop a second string class for purpose x.
> 
> 
> I reckon what we have in D is better than a class, it's extensible, you  can pretty much write your own 'methods' for the char[] type.
> 
> Regan

But if you want to abstact from the encoding you need a class,
or there is another D feature, that helps with that? :>

Roberto Mariottini wrote:

>>I just meant that Java and Java 2 are really different beasts ?
>>And some say that JDK 1.5 really forms a new "Java 3" language.
> 
> This doesn't change anything. The success of Java is due to having a big (and
> bigger, and bigger) library and a working (and better, and better) GUI from the
> beginning. JBuilder, Visual Age, and other IDE did the rest.
> Theese three items made the big Java commercial success.

As long as it doesn't delay the release of D 1.0 (indefinitely ?),
I don't have a problem with it having a kickass standard library :-)

But if it does, I would rather have some simple stuff in D 1.0 and
save the rest of it for D 2.0 instead ? It'll probably change, too.

Even if this means that the Template Library and Widget Toolkit
has to wait. There's still the C stdlib, and 3rd party libraries ?

Just thought it better to finalize the D language specification and
fix the compiler bugs, and worry about the libraries once that's done.

--anders

On Fri, 04 Mar 2005 09:26:29 +0100, Jan-Eric Duden <jeduden@whisset.com> wrote:
> Regan Heath wrote:
>> On Thu, 03 Mar 2005 23:28:20 +0100, Jan-Eric Duden <jeduden@whisset.com>  wrote:
>>
>>> Walter wrote:
>>>
>>>> "Mike Parker" <aldacron71@yahoo.com> wrote in message
>>>> news:d07dbj$24e$1@digitaldaemon.com...
>>>>
>>>>> For the C++ types, I think an STL equivalent is the big thing. To this
>>>>> end, I really believe either DTL or MinTL needs to be integrated into
>>>>> core Phobos as part of a 1.0 release. This will make people in both
>>>>> camps happy (Java developers love their Collections).
>>>>
>>>>   I understand that, but a DTL is probably going to be a D 2.0 feature.  But
>>>> part of the problem is a perception issue. D handles already, in the  core
>>>> language, much of the functionality of STL. (For an example, see
>>>> www.digitalmars.com/d/cppstrings.html) People briefly look at D, and  wonder
>>>> where the 'string class' is. It takes a bit more in depth look at D to
>>>> realize that a string class for D would be redundant, as would be vector
>>>> classes, slice classes, for_each kludges, hash collections, etc. One  other
>>>> large reason for the existence of STL is memory management. D does  automatic
>>>> memory management.
>>>>  DTL needs go at least one or two conceptual steps beyond STL, because D
>>>> already handles much of the core point of STL.
>>>>
>>> On the other hand, you still want to provide a standard string class.
>>>
>>> 1. A string class comes handy with the methods like  toUpper,toLower,replaceChar,findNextToken and so on.
>>> 2. A string class can abstract from the actual encoding UTF-8,  UTF-16,UTF-32 and can provide automatic conversions.
>>> 3. It provides a consistent way to access functions that work on strings.
>>>
>>> There are probably more things that a string class could provide.
>>> Some of the functions can be just global functions, but I think
>>> a lot of people are used access them as methods.
>>>
>>> Here an example:
>>>
>>> D right now:
>>>
>>> char[] s;
>>> s.length <- property
>>> toUTF32(s) <- global function
>>>
>>> D with a standardized string class
>>>
>>> string s;
>>>
>>> s.length()  <- method
>>> s.toUTF32() <- method
>>>
>>> This is much more consistent.
>>   You can already use the syntax above. D allows you to call a function  which takes an array as it's first parameter as if it was a  method/property of the array.
>>  eg.
>>  char[] s,p;
>> p = s.toTUF32();
>>
>>> Since strings are so fundamental, there should be a single standardized
>>> string interface. It needs to be powerful enough so that there is no  reason for anyone to develop a second string class for purpose x.
>>   I reckon what we have in D is better than a class, it's extensible, you  can pretty much write your own 'methods' for the char[] type.
>>  Regan
>
> But if you want to abstact from the encoding you need a class,
> or there is another D feature, that helps with that? :>

Why do you want to abstract the encoding? Can you give me an example where it's useful?

Regan

Jan-Eric Duden wrote:

>> I reckon what we have in D is better than a class, it's extensible, you  can pretty much write your own 'methods' for the char[] type.
> 
> But if you want to abstact from the encoding you need a class,
> or there is another D feature, that helps with that? :>

D isn't all that keen on "abstraction", from what I've seen.

It prefers the boolean variables implemented as integers
and the strings as dynamic arrays of unicode code units...
Otherwise some critical performance issue might be hidden
from the programmer, such as choosing the correct one of
the various available: bool/wbool/dbool and str/wstr/dstr
(bit/byte/int and char[]/wchar[]/dchar[] without aliases)

Perhaps you were thinking of a coffee-flavored language ? :-P

--anders

Regan Heath wrote:
> On Fri, 04 Mar 2005 09:26:29 +0100, Jan-Eric Duden <jeduden@whisset.com>  wrote:
> 
>> Regan Heath wrote:
>>
>>> On Thu, 03 Mar 2005 23:28:20 +0100, Jan-Eric Duden  <jeduden@whisset.com>  wrote:
>>>
>>>> Walter wrote:
>>>>
>>>>> "Mike Parker" <aldacron71@yahoo.com> wrote in message
>>>>> news:d07dbj$24e$1@digitaldaemon.com...
>>>>>
>>>>>> For the C++ types, I think an STL equivalent is the big thing. To  this
>>>>>> end, I really believe either DTL or MinTL needs to be integrated into
>>>>>> core Phobos as part of a 1.0 release. This will make people in both
>>>>>> camps happy (Java developers love their Collections).
>>>>>
>>>>>
>>>>>   I understand that, but a DTL is probably going to be a D 2.0  feature.  But
>>>>> part of the problem is a perception issue. D handles already, in the   core
>>>>> language, much of the functionality of STL. (For an example, see
>>>>> www.digitalmars.com/d/cppstrings.html) People briefly look at D, and   wonder
>>>>> where the 'string class' is. It takes a bit more in depth look at D to
>>>>> realize that a string class for D would be redundant, as would be  vector
>>>>> classes, slice classes, for_each kludges, hash collections, etc. One   other
>>>>> large reason for the existence of STL is memory management. D does   automatic
>>>>> memory management.
>>>>>  DTL needs go at least one or two conceptual steps beyond STL,  because D
>>>>> already handles much of the core point of STL.
>>>>>
>>>> On the other hand, you still want to provide a standard string class.
>>>>
>>>> 1. A string class comes handy with the methods like   toUpper,toLower,replaceChar,findNextToken and so on.
>>>> 2. A string class can abstract from the actual encoding UTF-8,   UTF-16,UTF-32 and can provide automatic conversions.
>>>> 3. It provides a consistent way to access functions that work on  strings.
>>>>
>>>> There are probably more things that a string class could provide.
>>>> Some of the functions can be just global functions, but I think
>>>> a lot of people are used access them as methods.
>>>>
>>>> Here an example:
>>>>
>>>> D right now:
>>>>
>>>> char[] s;
>>>> s.length <- property
>>>> toUTF32(s) <- global function
>>>>
>>>> D with a standardized string class
>>>>
>>>> string s;
>>>>
>>>> s.length()  <- method
>>>> s.toUTF32() <- method
>>>>
>>>> This is much more consistent.
>>>
>>>   You can already use the syntax above. D allows you to call a  function  which takes an array as it's first parameter as if it was a   method/property of the array.
>>>  eg.
>>>  char[] s,p;
>>> p = s.toTUF32();
>>>
>>>> Since strings are so fundamental, there should be a single standardized
>>>> string interface. It needs to be powerful enough so that there is no   reason for anyone to develop a second string class for purpose x.
>>>
>>>   I reckon what we have in D is better than a class, it's extensible,  you  can pretty much write your own 'methods' for the char[] type.
>>>  Regan
>>
>>
>> But if you want to abstact from the encoding you need a class,
>> or there is another D feature, that helps with that? :>
> 
> 
> Why do you want to abstract the encoding? Can you give me an example where  it's useful?
> 
> Regan
For example:
You have a library A that works utf8 characters and
you have a library B that works utf16 characters.

And you are writing a program using A and B,
then you need to write either a wrapper around A or B or you need to make conversion calls in every call of functions that belong to these libraries.

A string class can help here.

Furthermore a string class can help implementing the concept "copy only if changes are made".

This is pretty important since D doesn't support the keyword const.

Otherwise every single class that wants to store a string needs to copy the string!

In article <d0967b$fo2$2@digitaldaemon.com>, =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
>
[..]
>
>As long as it doesn't delay the release of D 1.0 (indefinitely ?),
>I don't have a problem with it having a kickass standard library :-)
>
>But if it does, I would rather have some simple stuff in D 1.0 and save the rest of it for D 2.0 instead ? It'll probably change, too.

In my original post I was saying that the "D language specification 1.0" is
nearly ready. And the "D 1.0 reference compiler" is close.
And that when those are released, D is still not commercially viable.

>Even if this means that the Template Library and Widget Toolkit has to wait. There's still the C stdlib, and 3rd party libraries ?

All languages have 3rd party libraries, but successful ones (in the 2000s) have a big standard library. You can alwais add 3rd party libraries, if you want.

>Just thought it better to finalize the D language specification and fix the compiler bugs, and worry about the libraries once that's done.

That's good for me.
It's only that I still can't use D at work.

Ciao

Roberto Mariottini wrote:

>>Just thought it better to finalize the D language specification and
>>fix the compiler bugs, and worry about the libraries once that's done.
> 
> That's good for me.
> It's only that I still can't use D at work.

Me neither. Then again, had I bothered about that I'd be coding
Visual Basic by now. Or, more likely, doing something else...

Fishing, perhaps ? :-)
> I could have been anything. I could have been a fisherman.
> Fishermen, they get up in the morning, they fish, they sell fish,
> they smell fish. Reminds me of a girl I used to go with, Yvonne.
> She smelled like fish.

Nah, D will do... I'm just using it to stay off the C++, anyway.
Otherwise I'm using C or Java. But mostly Perl and sh, actually.

--anders

Anders F Björklund wrote:
> Jan-Eric Duden wrote:
> 
>>> I reckon what we have in D is better than a class, it's extensible, you  can pretty much write your own 'methods' for the char[] type.
>>
>>
>> But if you want to abstact from the encoding you need a class,
>> or there is another D feature, that helps with that? :>
> 
> 
> D isn't all that keen on "abstraction", from what I've seen.
> 
> It prefers the boolean variables implemented as integers
> and the strings as dynamic arrays of unicode code units...
> Otherwise some critical performance issue might be hidden
> from the programmer, such as choosing the correct one of
> the various available: bool/wbool/dbool and str/wstr/dstr
> (bit/byte/int and char[]/wchar[]/dchar[] without aliases)
> 
> Perhaps you were thinking of a coffee-flavored language ? :-P
> 
> --anders
I don't like coffee. :>
Eventhough java is not the slowest language ever anymore,
it still has a lot of drawbacks.

Who wants to ship the whole JRE to their customers? That only works well in controlled environments.
MS makes the same mistake with their .NET framework binaries...

That's why I like D.

On Fri, 04 Mar 2005 09:45:59 +0100, Jan-Eric Duden <jeduden@whisset.com> wrote:
>>> But if you want to abstact from the encoding you need a class,
>>> or there is another D feature, that helps with that? :>
>>   Why do you want to abstract the encoding? Can you give me an example where  it's useful?
>>  Regan
> For example:
> You have a library A that works utf8 characters and
> you have a library B that works utf16 characters.
>
> And you are writing a program using A and B,
> then you need to write either a wrapper around A or B or you need to make conversion calls in every call of functions that belong to these libraries.

Correct. But, all you'd be achieving is shorter code which hides the fact that it's converting strings all the time.

Ideally we should only convert on input and output.
Ideally we use the most efficient format (depends on our task) internally.

Of course things seldom happen that way and I guess if efficiency isn't that important then a string class might be nice, but it's not essential.

Question, I believe opCast can only be overloaded for one type, so, how you return char[], wchar[] and dchar[] without using method calls?

> Furthermore a string class can help implementing the concept "copy only if changes are made".

"Copy On Write"

> This is pretty important since D doesn't support the keyword const.

I think the need for const is obviated somewhat by in, out and inout.
It would be obviated further if constness was enforced when 'in' was used.
eg.

If you see: void foo(inout char[] a), you know foo will/might modify 'a'
If you see: void foo(char[] a), you know foo won't modify 'a' (not actually true*)

*foo can modify the data but not the reference, eg.

void foo(char[] a) {
  a[0] = '1';
}

will modify the first char of a.

I think the constness of 'in' idea is very important, it gives us some assurances and allows us to implement "Copy On Write" more confidently.

> Otherwise every single class that wants to store a string needs to copy the string!

Correction, every single class that wants "to modify" a string *it has stored* needs to copy the string. In other words "Copy On Write".

Regan