http://www-128.ibm.com/developerworks/java/library/j-jtp02183.html

Does anyone else (Kris?) feel an urgent need for some immutable basic data types in D? Especially in light of the recent plan to translate SWT -> DWT and possible other Java projects in the future. IMHO D should at least provide immutable strings. I'm sure we all agree -- it has been discussed before -- that having some light-weight immutable data types is a good thing in the context of scalable, multi-threaded, GC-enabled programs. Now it just seems more urgent...

Kris, I imagine your translator will be dependent not on just the D language, but also a library, right? If so, which one?

Matthias

"Matthias Spycher" <matthias@coware.com> wrote in message news:dsdc9n$20dh$1@digitaldaemon.com...
> http://www-128.ibm.com/developerworks/java/library/j-jtp02183.html
>
> Does anyone else (Kris?) feel an urgent need for some immutable basic data types in D? Especially in light of the recent plan to translate SWT -> DWT and possible other Java projects in the future. IMHO D should at least provide immutable strings. I'm sure we all agree -- it has been discussed before -- that having some light-weight immutable data types is a good thing in the context of scalable, multi-threaded, GC-enabled programs. Now it just seems more urgent...

The problem with some sort of immutable data type is there are at least a dozen different ways to do it. A lot more thinking has to go into this, less we get stuck with a poor design like C++'s.

"Matthias Spycher" <matthias@coware.com> wrote...
> http://www-128.ibm.com/developerworks/java/library/j-jtp02183.html
>
> Does anyone else (Kris?) feel an urgent need for some immutable basic data types in D? Especially in light of the recent plan to translate SWT -> DWT and possible other Java projects in the future. IMHO D should at least provide immutable strings. I'm sure we all agree -- it has been discussed before -- that having some light-weight immutable data types is a good thing in the context of scalable, multi-threaded, GC-enabled programs. Now it just seems more urgent...

Mango has a number of immutable and pseudo-immutable classes (you can still bork the latter type given the lack of compiler support). It turns out that they're not actually needed for SWT ~ not even mango.text.String. While I agree that support for immutability should probably be a pre-requisite for a language that claims to support concurrency, Walter clearly feels it's pretty low on the priority list. We can but hope it will arrive in due time <g>

> Kris, I imagine your translator will be dependent not on just the D language, but also a library, right? If so, which one?

Mango!

Walter Bright wrote:
> 
> The problem with some sort of immutable data type is there are at least a dozen different ways to do it. A lot more thinking has to go into this, less we get stuck with a poor design like C++'s. 

Definately.  While I find the idea appealing, I would prefer to approach it carefully.  Particularly since the more straightforward approaches (such as making 'const' a logical qualifier) seem likely to break a tremendous amount of code in ways that might not be so easy to fix.


Sean

"Walter Bright" <newshound@digitalmars.com> wrote in message news:dsdn6t$289j$3@digitaldaemon.com...
>
> "Matthias Spycher" <matthias@coware.com> wrote in message news:dsdc9n$20dh$1@digitaldaemon.com...
>> http://www-128.ibm.com/developerworks/java/library/j-jtp02183.html
>>
>> Does anyone else (Kris?) feel an urgent need for some immutable basic data types in D? Especially in light of the recent plan to translate SWT -> DWT and possible other Java projects in the future. IMHO D should at least provide immutable strings. I'm sure we all agree -- it has been discussed before -- that having some light-weight immutable data types is a good thing in the context of scalable, multi-threaded, GC-enabled programs. Now it just seems more urgent...
>
> The problem with some sort of immutable data type is there are at least a dozen different ways to do it. A lot more thinking has to go into this, less we get stuck with a poor design like C++'s.
>

I would rise this question again:

Is it possible to declare (typedef) new array type with all mutating methods
disabled?
Sort of:
typedef char[] string ( no opIndexAssign; no void length(int) )

This will be pretty sufficient for strings and other cases.
In any case ability to create new types from intrinsic types is a good thing
in D.
But it is a half. It should be a mechanism of declaring also set of
operations allowed.

Again, array as a builtin feature lacks their immutable counterparts in D typesystem.

Andrew.

Andrew Fedoniouk wrote:
> "Walter Bright" <newshound@digitalmars.com> wrote in message news:dsdn6t$289j$3@digitaldaemon.com...
>> "Matthias Spycher" <matthias@coware.com> wrote in message news:dsdc9n$20dh$1@digitaldaemon.com...
>>> http://www-128.ibm.com/developerworks/java/library/j-jtp02183.html
>>>
>>> Does anyone else (Kris?) feel an urgent need for some immutable basic data types in D? Especially in light of the recent plan to translate SWT -> DWT and possible other Java projects in the future. IMHO D should at least provide immutable strings. I'm sure we all agree -- it has been discussed before -- that having some light-weight immutable data types is a good thing in the context of scalable, multi-threaded, GC-enabled programs. Now it just seems more urgent...
>> The problem with some sort of immutable data type is there are at least a dozen different ways to do it. A lot more thinking has to go into this, less we get stuck with a poor design like C++'s.
>>
> 
> I would rise this question again:
> 
> Is it possible to declare (typedef) new array type with all mutating methods disabled?
> Sort of:
> typedef char[] string ( no opIndexAssign; no void length(int) )
> 
> This will be pretty sufficient for strings and other cases.

const char[] ar = "hello world";
char* c = &ar[0];
c = 'j';

I grant that it's a corner case, but worth noting nevertheless.


Sean

>> I would rise this question again:
>>
>> Is it possible to declare (typedef) new array type with all mutating
>> methods disabled?
>> Sort of:
>> typedef char[] string ( no opIndexAssign; no void length(int) )
>>
>> This will be pretty sufficient for strings and other cases.
>
> const char[] ar = "hello world";
> char* c = &ar[0];
> c = 'j';
>
> I grant that it's a corner case, but worth noting nevertheless.
>

In C++ I am enabling:
  T operator []
and disabling:
   T& operator []
in such cases.

But as you said "it's a corner case".

cast() is there and you may
do scarry things with it and this is not an argument to disable raw cast in
the language, right?

Andrew.

I agree, it's not an easy task in general. But a simple final String class that prevents (as much as possible) all direct access to the underlying array of characters in its API would go a long way already, no? If the API exposed only dchar values (for accessing individual characters), you would not expose the actual implementation, which might be optimized during construction.

Immutability implies sharing, so these objects are more likely to be allocated on the heap, and I imagine the garbage collector could provide an interning service for them.

The implementation of java.lang.String has evolved quite a bit over the years, despite the fact that it deals with only one type of char. I don't expect the evolution of a D.String to be any different. Certainly, having minimal support for immutable strings in D 1.0 has to be better than no support at all.

Matthias

Walter Bright wrote:
> 
> The problem with some sort of immutable data type is there are at least a dozen different ways to do it. A lot more thinking has to go into this, less we get stuck with a poor design like C++'s. 
> 
> 

I'd like to add that from my 6 years with C++, I have never been _saved_ ( to my knowledge -- knock on wood ) by const.  And I must have typed it thousands of times .

Not that Im voting against immutability, only that if it does get added its as non-intrusive as possible.  But I really don't want to start another debate!

Charlie

"Walter Bright" <newshound@digitalmars.com> wrote in message news:dsdn6t$289j$3@digitaldaemon.com...
>
> "Matthias Spycher" <matthias@coware.com> wrote in message news:dsdc9n$20dh$1@digitaldaemon.com...
> > http://www-128.ibm.com/developerworks/java/library/j-jtp02183.html
> >
> > Does anyone else (Kris?) feel an urgent need for some immutable basic
data
> > types in D? Especially in light of the recent plan to translate SWT ->
DWT
> > and possible other Java projects in the future. IMHO D should at least provide immutable strings. I'm sure we all agree -- it has been
discussed
> > before -- that having some light-weight immutable data types is a good thing in the context of scalable, multi-threaded, GC-enabled programs.
Now
> > it just seems more urgent...
>
> The problem with some sort of immutable data type is there are at least a dozen different ways to do it. A lot more thinking has to go into this,
less
> we get stuck with a poor design like C++'s.
>
>

"Charles" <noone@nowhere.com> wrote in message news:dsfnlr$247h$1@digitaldaemon.com...
>
> I'd like to add that from my 6 years with C++, I have never been _saved_ ( to my knowledge -- knock on wood ) by const.  And I must have typed it thousands of times .
>
> Not that Im voting against immutability, only that if it does get added
> its
> as non-intrusive as possible.  But I really don't want to start another
> debate!
>

Well it is different point of view and it is perfectly valid. For you and for me.

The thing is simple: const is a declartion - meta information if you wish. const is more collaborative tool than probably anything else.

It is seems like for Walter too - const worth nothing because he is working on his own codebase and he knows *his own* code very well.

But we have completely different story in team projects.

See, partner developers from China will send us class:

class Record
{
    Field[] fields();
}

Do you have any idea of how you can use this fields?
Can you change fieldset or not?

Again, for a lone-code-wolf writing 50000 lines code in three months const is (probably) just nothing if not worse - more chars to type.

For the team it is a way to reduce needed documentation for example - quite opposite to your situation.

C++ and C99 has "char[]" and "const char[]" which are  two distinct types.

D has only one char[]. Step back? Yes.

Again, it seems that having readonly array  type (like  char#[] ) will allow to reduce problem significantly. For classes and objects you can create readonly envelopes, but arrays are naked in this regard.

You can create as many meta programming features as you wish but without such basic feature your type system is just


Andrew.