Sharing in D

[Sean Kelly]

== Quote from Steven Schveighoffer (schveiguy at yahoo.com)'s 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.


Sean