|
Archives
D Programming
digitalmars.D
digitalmars.D.bugs
digitalmars.D.dtl
digitalmars.D.ide
digitalmars.D.dwt
digitalmars.D.announce
digitalmars.D.learn
digitalmars.D.debugger
D.gnu
D
C/C++ Programming
c++
c++.announce
c++.atl
c++.beta
c++.chat
c++.command-line
c++.dos
c++.dos.16-bits
c++.dos.32-bits
c++.idde
c++.mfc
c++.rtl
c++.stl
c++.stl.hp
c++.stl.port
c++.stl.sgi
c++.stlsoft
c++.windows
c++.windows.16-bits
c++.windows.32-bits
c++.wxwindows
digitalmars.empire
digitalmars.DMDScript
electronics
|
digitalmars.D.dwt - 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
"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.
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...
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
types in D? Especially in light of the recent plan to translate SWT ->
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
before -- that having some light-weight immutable data types is a good
thing in the context of scalable, multi-threaded, GC-enabled programs.
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,
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.
Andrew Fedoniouk wrote:
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.
Frankly, I have far more problems with people just not writing
meaningful code. For example:
class C {
public:
Thing* getThing();
};
Who owns the Thing returned by C? And is Thing even dynamically
allocated? auto_ptr was designed for this purpose, but no seems to use
it correctly:
class C {
public:
std::auto_ptr<Thing> getThing();
};
Here, the transferral of ownership indicated by the syntax, as is the
fact that Thing was allocated on the heap.
The same could be said of const qualifiers. In my experience, little
thought often goes into what is made 'const' and what isn't, and
deciphering this later is a maintenance nightmare. Pointers are another
problem area, as many people don't seem aware that "int const *const" is
a legal statement, or know what the position of each 'const' implies.
In summary, I agree that 'const' can be useful in Ivory Tower type
programming. But unfortunately, I seem to keep being called out to the
docks. If someone can come up with a form of immutability that is both
elegant and meaningful I'll be cheering for its inclusion in D. But I'm
beginning to agree with Walter that the C++ implementation can
deceptive, which greatly reduces its utility.
Sean
"Sean Kelly" <sean f4.ca> wrote in message
news:dsgie6$2lap$1 digitaldaemon.com...
Andrew Fedoniouk wrote:
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.
Frankly, I have far more problems with people just not writing meaningful
code. For example:
class C {
public:
Thing* getThing();
};
Who owns the Thing returned by C? And is Thing even dynamically
allocated? auto_ptr was designed for this purpose, but no seems to use it
correctly:
class C {
public:
std::auto_ptr<Thing> getThing();
};
Let's say you need to create bullet-proof library of the things
Then it is just enough to declare:
class Thing
{
package ~this();
}
Having this no one auto_ptr will accept it and user will
get an idea that this Thing is managed by Things package.
No documentation needed and compiler will enforce this.
Here, the transferral of ownership indicated by the syntax, as is the fact
that Thing was allocated on the heap.
Yep, "Show me your destructor and I will tell you what policy do you use"
The same could be said of const qualifiers. In my experience, little
thought often goes into what is made 'const' and what isn't, and
deciphering this later is a maintenance nightmare. Pointers are another
problem area, as many people don't seem aware that "int const *const" is a
legal statement, or know what the position of each 'const' implies.
I understand that this const * (const *) notation in C++ is just a ... you
know what.
Trust me, I understand Walter's concerns and know them too well.
In summary, I agree that 'const' can be useful in Ivory Tower type
programming. But unfortunately, I seem to keep being called out to the
docks. If someone can come up with a form of immutability that is both
elegant and meaningful I'll be cheering for its inclusion in D. But I'm
beginning to agree with Walter that the C++ implementation can deceptive,
which greatly reduces its utility.
Let me remind that idea of "practical immutability" again:
1) Now in D any user type (structure, class) can be designed to be explictly
immutable -
if you want some class of the package be immutable outside - declare
all its mutating methods with package attribute. Simple and is already
there.
2) arrays. array is a builtin *structure* in D with its own set of
operations:
There is no mechanism in D to declare readonly array.
Proposals: a) to introduce readonly array type e.g. as type#[].
b) -or- provide another way (e.g. extended typedef)
to explicily list operations allowed on the array
type.
3) pointers. The same problem and similar solution:
Introduce new readonly pointer type, e.g. #* e.g.
type#* rop;
so *rop cannot serve l-value purposes.
Implementation is simple, notation is simple - can be implemented reliably.
Andrew Fedoniouk.
http://terrainformatica.com
As much as I like the notion of immutable arrays, it is a tough
proposition in a language that directly exposes memory to the programmer
using pointers.
For an object-oriented language with a GC, I would propose a class-based
solution for immutable objects. They are good candidates for sharing, so
allocation on the heap will be frequent. In other words, the class
overhead is justifiable.
I think I'm on Walter's side regarding const; also for simplicity's sake.
Matthias
Andrew Fedoniouk wrote:
"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.
On Wed, 8 Feb 2006 13:10:19 -0800, 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.
This is an encouraging response, Walter. Previously I was under the
distinct impression that the whole idea of having the D language help
coders deal with concept of immutable data was against your philosophy.
This note of yours seems to be saying that you can see it happening in D,
but only after the right amount of thinking about 'how to do it well' has
occurred.
--
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
10/02/2006 10:09:47 AM
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.
Can someone tell more about what's wrong and/or what could be better
with C++'s design(const)?
--
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to
be... unnatural."
In article <dsil1d$1gs8$1 digitaldaemon.com>, Bruno Medeiros says...
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.
Can someone tell more about what's wrong and/or what could be better
with C++'s design(const)?
The issue is quite subjective. It depends on what you consider 'wrong'.
IMHO, const appears to be the way most of to many developers because that's what
its for. By its very nature, it is purposefully designed to make your life
harder all in the name of data integrity.
Now how it accomplishes that job and wether or not its doing it well is totally
up to debate. Personally, I find API authors abusing 'const' nearly as much as
API users abusing 'const_cast' so its kind of a toss-up.
---------------
As for D: if there was some way to impose the COW idiom on assigning from const
to non-const, then I think we'd have a superior solution. At a minimum this
would require const to only apply to primitive/scalar types which seems
acceptable: classes and structs at least have a way to protect their internals
via methods.
I'd also like to see 'readonly' used in favor of 'const'. A 'writable' modifier
would also make template programming easier, due to its symmetry (see below)
// to summarize the above:
readonly char[] x = "hello world";
char[] y = cast(char[])x; // Explicit cast from readonly triggers COW idiom
y[0..$] = "byebye world"; // legal (working with a copy of x)
x[0..$] = "byebye world"; // illegal (readonly)
readonly Foobar a = new Foobar(); // illegal: readonly not applicable to
classes
// example of using 'writable' (spoof of the ol' const-cast)
template(writable T) const_cast{
T foobar(readonly T arg){
return cast(writable)arg;
}
}
- Eric Anderton at yahoo
I'd also like to see 'readonly' used in favor of 'const'. A 'writable'
modifier
would also make template programming easier, due to its symmetry (see
below)
// to summarize the above:
readonly char[] x = "hello world";
char[] y = cast(char[])x; // Explicit cast from readonly triggers COW
idiom
y[0..$] = "byebye world"; // legal (working with a copy of x)
x[0..$] = "byebye world"; // illegal (readonly)
readonly Foobar a = new Foobar(); // illegal: readonly not applicable to
classes
// example of using 'writable' (spoof of the ol' const-cast)
template(writable T) const_cast{
T foobar(readonly T arg){
return cast(writable)arg;
}
}
Exactly.
Thought about decorations:
In phrase 'readonly char[]' readonly is in fact a part of array type
modifier ([])
so semanticly speaking it should look like 'char readonly []' -
in short : "char #[]" where '#' means exactly "no-assignment allowed".
Second one about "Explicit cast from readonly triggers COW idiom"
I think that cast should be a cast as it is now.
dup is already there for that purposes. No?
Andrew.
In article <dsk7ch$qmm$1 digitaldaemon.com>, Andrew Fedoniouk says...
I'd also like to see 'readonly' used in favor of 'const'. A 'writable'
modifier
would also make template programming easier, due to its symmetry (see
below)
// to summarize the above:
readonly char[] x = "hello world";
char[] y = cast(char[])x; // Explicit cast from readonly triggers COW
idiom
y[0..$] = "byebye world"; // legal (working with a copy of x)
x[0..$] = "byebye world"; // illegal (readonly)
readonly Foobar a = new Foobar(); // illegal: readonly not applicable to
classes
// example of using 'writable' (spoof of the ol' const-cast)
template(writable T) const_cast{
T foobar(readonly T arg){
return cast(writable)arg;
}
}
Exactly.
Thought about decorations:
In phrase 'readonly char[]' readonly is in fact a part of array type
modifier ([])
so semanticly speaking it should look like 'char readonly []' -
in short : "char #[]" where '#' means exactly "no-assignment allowed".
Second one about "Explicit cast from readonly triggers COW idiom"
I think that cast should be a cast as it is now.
dup is already there for that purposes. No?
I disagree. Readonly means more than "don't assign to me". It should also
mean, "the data I point to is protected". Sure, you could emulate this with a
dup but its much cleaner if it is an assumed operation when casting to and from
readonly*.
One of the pitfalls of the C's const design was that the best that could
possibly be accomplished by the complier is a static cast. In D, we have a
garbage collector, so we can automatically enforce the readonly integrity of the
original const data by performing a copy on cast. This will lead to fewer
errors and make things more failsafe by strictly maintaining readonly and
writable sets of data.**
Also, the '#' symbol is reserved by the lexer for compiler directives. Using it
in the way you suggest makes D's syntax context-sensitive; something that Walter
has been quite adamant about avoiding. For instance, how would you expect the
following to compile?
char
#[] foobar;
IMO, we're better off using no-nonsense modifiers like 'readonly' and
'writeable' as there's zero room to debate what they actually mean, or how to
parse them.
* Casting from writable to readonly should also copy as to ensure that writable
and readable data remain distinct and protected. I'd anticipate that .dup on
array operations would also inherit the parent's readonly/writable attributes,
so slices would have to be cast in a similar way. This would ensure that
aliases to readonly data would in themselves be readonly.
** Of course you can always throw caution to the wind by casting through void*,
which would avoid any copying by not explicitly casting to/from readonly.
- Eric Anderton at yahoo
"pragma" <pragma_member pathlink.com> wrote in message
news:dskoas$1u2n$1 digitaldaemon.com...
In article <dsk7ch$qmm$1 digitaldaemon.com>, Andrew Fedoniouk says...
I'd also like to see 'readonly' used in favor of 'const'. A 'writable'
modifier
would also make template programming easier, due to its symmetry (see
below)
// to summarize the above:
readonly char[] x = "hello world";
char[] y = cast(char[])x; // Explicit cast from readonly triggers COW
idiom
y[0..$] = "byebye world"; // legal (working with a copy of x)
x[0..$] = "byebye world"; // illegal (readonly)
readonly Foobar a = new Foobar(); // illegal: readonly not applicable
to
classes
// example of using 'writable' (spoof of the ol' const-cast)
template(writable T) const_cast{
T foobar(readonly T arg){
return cast(writable)arg;
}
}
Exactly.
Thought about decorations:
In phrase 'readonly char[]' readonly is in fact a part of array type
modifier ([])
so semanticly speaking it should look like 'char readonly []' -
in short : "char #[]" where '#' means exactly "no-assignment allowed".
Second one about "Explicit cast from readonly triggers COW idiom"
I think that cast should be a cast as it is now.
dup is already there for that purposes. No?
I disagree. Readonly means more than "don't assign to me". It should
also
mean, "the data I point to is protected". Sure, you could emulate this
with a
dup but its much cleaner if it is an assumed operation when casting to and
from
readonly*.
One of the pitfalls of the C's const design was that the best that could
possibly be accomplished by the complier is a static cast. In D, we have
a
garbage collector, so we can automatically enforce the readonly integrity
of the
original const data by performing a copy on cast. This will lead to fewer
errors and make things more failsafe by strictly maintaining readonly and
writable sets of data.**
Ideally yes, but practically you *will* have situations
when you need to remove 'constness' from particular readonly
data chunk - for example - passing string to some external API and
libraries.
The whole idea of having readonly arrays/pointers - provide
declarative readonliness but keep implementation effective as it is.
So instead of:
readonly char[] x = "hello world";
char[] y = cast(char[])x; // Explicit cast from readonly triggers COW
you will write:
readonly char[] x = "hello world";
char[] y = x.dup; // Explicit copy
- more clear I believe.
Also, the '#' symbol is reserved by the lexer for compiler directives.
Using it
in the way you suggest makes D's syntax context-sensitive; something that
Walter
has been quite adamant about avoiding. For instance, how would you expect
the
following to compile?
char
#[] foobar;
IMO, we're better off using no-nonsense modifiers like 'readonly' and
'writeable' as there's zero room to debate what they actually mean, or how
to
parse them.
#* and #[ are single tokens with one character lookahead.
D tokenizer is already doing this stuff everywhere.
! and != , < and <=, + and ++, etc.
* Casting from writable to readonly should also copy as to ensure that
writable
and readable data remain distinct and protected. I'd anticipate that .dup
on
array operations would also inherit the parent's readonly/writable
attributes,
so slices would have to be cast in a similar way. This would ensure that
aliases to readonly data would in themselves be readonly.
Runtime and compiler has no way to enforce "data remain distinct and
protected"
in 100%.
The *only* thing what compiler can verify and enforce is that:
particular readonly pointer has no operartion "l-value dereferencing"
The same apply to readonly arrays.
It is a task of the same complexity for compiler as to determine if class
Foo
has method Bar - not more.
Other meanings of const and readonly, is a pitty, but just dreams.
** Of course you can always throw caution to the wind by casting through
void*,
which would avoid any copying by not explicitly casting to/from readonly.
Andrew.
"Bruno Medeiros" <daiphoenixNO SPAMlycos.com> wrote in message
news:dsil1d$1gs8$1 digitaldaemon.com...
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.
C++'s design(const)?
"const" has many possible meanings:
1) is the data immutable and set at compile time, so it could be put in ROM?
2) is the pointer itself const, or is the data it points to const?
3) does const mean write-once, i.e. can it be initialized at runtime?
4) can other references to the same data change it?
5) can "constness" be cast away?
6) if one has a "const" array of objects, is the array reference const, the
array contents const, or are the object contents const? What about what
those objects refer to?
7) what about "logical" constness, where data can appear to be constant but
has, in actuallity, "mutable" state? (see C++ "mutable" keyword)
And, of course, every combination of the above.
"Walter Bright" <newshound digitalmars.com> wrote in message
news:dsjq1j$5rv$2 digitaldaemon.com...
"Bruno Medeiros" <daiphoenixNO SPAMlycos.com> wrote in message
news:dsil1d$1gs8$1 digitaldaemon.com...
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.
C++'s design(const)?
"const" has many possible meanings:
1) is the data immutable and set at compile time, so it could be put in
ROM?
2) is the pointer itself const, or is the data it points to const?
In C/C++ declaration of const pointer is like this:
const typename * -or-
typename const *
this is just bad - two tokens used in arbitrary order (who invented this?)
for declaration of const-ptr.
Proposed schema of readonly pointers uses single token '#*'
type #* p;
3) does const mean write-once, i.e. can it be initialized at runtime?
void foo( bar #* p )
means that in scope of function foo
'*p' cannot be an l-value.
4) can other references to the same data change it?
yes.
5) can "constness" be cast away?
yes. cast is a brute force and last resort but usable. Even Prof. Niklaus
Wirth agree with this.
6) if one has a "const" array of objects, is the array reference const,
the array contents const, or are the object contents const? What about
what those objects refer to?
bar #[] ar;
means that type 'bar #[]' has no operations changing
content of the array's raw data (in range ptr...ptr+length )
and pseudo fields ptr and length cannot be changed.
Implication: its pseudo variable ptr is type of bar #*
7) what about "logical" constness, where data can appear to be constant
but has, in actuallity, "mutable" state? (see C++ "mutable" keyword)
This is not applicable in D. All objects (instances of some class) are
mutable
by definition.
And, of course, every combination of the above.
Well, not too much left.
The only problem I see is what to do
with structures:
struct myst
{
int a;
void m(int b) { a = b; }
}
myst# *pms = ...;
myst ms = ...;
I think this would be enough:
pms.a = 1; // compile time error - attempt to modify data at location
pointed by readonly pointer.
- but -
pms.m(2); // is fine - author of the type provided explicit mutator.
ms = *pms; // is fine - creation of local copy of the variable with
// possible modification of that copy.
Andrew Fedoniouk.
http://terrainformatica.com
"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!
|
|
C & C++
DMDScript
Sean Kelly <sean f4.ca> 