Thread overview | |||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
February 08, 2006 To mutate or not to mutate? | ||||
---|---|---|---|---|
| ||||
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 |
February 08, 2006 Re: To mutate or not to mutate? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Matthias Spycher | "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. |
February 08, 2006 Re: To mutate or not to mutate? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Matthias Spycher | "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! |
February 08, 2006 Re: To mutate or not to mutate? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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
|
February 08, 2006 Re: To mutate or not to mutate? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | "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. |
February 08, 2006 Re: To mutate or not to mutate? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrew Fedoniouk | 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
|
February 08, 2006 Re: To mutate or not to mutate? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sean Kelly |
>> 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.
|
February 09, 2006 Re: To mutate or not to mutate? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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.
>
>
|
February 09, 2006 Re: To mutate or not to mutate? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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. > > |
February 09, 2006 Re: To mutate or not to mutate? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Charles | "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. |
Copyright © 1999-2021 by the D Language Foundation