Sharing in D

[Sean Kelly]

== Quote from Steven Schveighoffer (schveiguy at yahoo.com)'s article
> "Sean Kelly" wrote
> > == Quote from Steven Schveighoffer article
> >> "Walter Bright" wrote
> >> > Steven Schveighoffer wrote:
> >> >> "Walter Bright" wrote
> >> >>> Nearly all global data is assumed to be and treated as if it were
> >> >>> unshared. So making unshared the default is the right solution. And
> >> >>> frankly, if you're using a lot of global variables, you might want to
> >> >>> reevaluate what you're doing. Lots of global variables is the 80's
> >> >>> style
> >> >>> of programming :-)
> >> >> I have no idea where you came up with this.  To me global means
> >> >> shared.
> >> >> Global means the world can see it, meaning that it's shared between
> >> >> all.
> >> >> Even VB.net uses 'Shared' as the keyword to mean 'global'
> >> >
> >> > The idea is that encapsulation is better, and having something shared
> >> > between everyone violates encapsulation. When you have a global
> >> > variable
> >> > 'int x' that everyone can read and write to, and there's a bug, you
> >> > have
> >> > the whole program to search for that bug. The principle of
> >> > encapsulation
> >> > is that each chunk of data is visible only to the code that needs to
> >> > see
> >> > it, and no more.
> >> So if I write:
> >> shared int x;
> >> As a global variable, how does this help encapsulation?  In the current
> >> model, if you need shared data, you use global variables.  If you don't
> >> need
> >> shared data, use member or stack variables.  My point is that what you
> >> will
> >> have done is just made the person who wants a global variable write
> >> 'shared'
> >> in front of it.  I don't see how this helps him protect the variable at
> >> all.
> >> It just seems like you are enforcing something that already can be
> >> enforced.
> >> > (Programming languages started out with everything being global data,
> >> > and
> >> > has moved away from that ever since.)
> >> I'm not advocating using global variables over stack or member variables.
> >> All I'm saying is that this 'shared/unshared' model doesn't seem to me
> >> like
> >> it will eliminate the need for threading constructs, or even help with
> >> it.
> >
> > I'm hoping that 'shared' will force programmers to think about what
> > they're
> > doing a bit more.  A typical multithreaded app should have extremely
> > little
> > shared data.  One thing I'm not sure of, though, is if I write a single-
> > threaded app, will I need to label anything shared?  Functionally I don't,
> > since having everything thread-local is exactly what I need, but I'm not
> > sure if the compiler will yell at me anyway.  I'm guessing it will, which
> > would be a bit annoying, but it would "future proof" the app for adding
> > multithreading later, so perhaps it's okay.
> I'm thinking more in the case of functions.  If I have a function foo, and I
> want to pass my shared data version to it, I need to re-implement foo with
> the parameters as being shared.  Imagine a function with several parameters,
> in which you want to pass a combination of shared/unshared.  That's 2^n
> variations you have to write.

Darnit, you're right.  That's just like 'volatile' in C++.  In fact,
it's the primary reason why I dislike the const system in D 2.0.

> I think at the very least, for this to be palatable, there needs to be
> another modifier that unifies shared and unshared.  Similar to how const
> unifies mutable and invariant.

You could be right.  Though that means yet another label and all the
baggage that goes with it.


Sean