thoughts on immutability in D
Jonathan M Davis
jmdavisProg at gmx.com
Sat Sep 24 00:07:35 PDT 2011
On Saturday, September 24, 2011 08:12:17 Rainer Schuetze wrote:
> On 9/22/2011 4:10 PM, Andrei Alexandrescu wrote:
> > On 9/22/11 3:02 AM, Peter Alexander wrote:
> >> On 22/09/11 7:04 AM, Andrei Alexandrescu wrote:
> >>> The initial submission got junked so I resubmitted:
> >>>
> >>> http://www.reddit.com/r/programming/comments/knn5p/thoughts_on_immut
> >>> ability_in_d/
> >>>
> >>>
> >>>
> >>> Andrei
> >>
> >> Thanks for the reddit'ing. I launched up google analytics this morning
> >> and noticed a sudden spike. That could only mean one thing :-)
> >>
> >> Out of interest, does anyone have any criticism of my post, esp. if
> >> there's any technical inaccuracies (or just disagreement?)
> >
> > You could have specified that e.g. mutable state can be implemented
> > safely with the help of a global hash table.
> >
> > Andrei
>
> If this is allowed by the compiler, doesn't that break all the
> guarantees transitive immutability tries to make? Aren't we back to
> "faith based programming" this way?
In a way, yes. No, the object itself isn't altered, but by using such a hash
table, you're effectively moving some of the state out of the class or struct.
That state is then not regulated by const. If you did that with all of a
type's member variables, then const would mean nothing. In order to truly
guarantee that this isn't an issue, you have to combine const with pure.
However, it _is_ a way to have an object primarily const and still have some
sort of logical const. Still, it strikes me as a bad idea unless you really
need it for some reason, and the fact that it makes it so that you can't use
pure is definitely not desirable.
- Jonathan M Davis
More information about the Digitalmars-d
mailing list