Robert Fraser wrote:

> Jarrett Billingsley wrote:
>> // should be immutable int[3], no?
>> immutable table[3] x = [6, 123, 0x87];
>
> Really shouldn't that be enum, unless you mysteriously needed to take the address of it?

Seeing as how the example is for immutable, I'd say enum wouldn't be
quite right.

--
 Simen

On Tue, 12 May 2009 13:47:02 -0400, Walter Bright <newshound1@digitalmars.com> wrote:

> I wrote a brief article which should help:
>
> http://www.digitalmars.com/d/2.0/migrate-to-shared.html

Regarding making globals immutable, one other option that was not identified was making it an enum.

Most of the time, I would think you'd want manifest constants versus immutable globals, as they take up no static space.

(not any more comments yet, still reading...)

-Steve

On Thu, 14 May 2009 08:54:21 -0400, Steven Schveighoffer <schveiguy@yahoo.com> wrote:

> On Tue, 12 May 2009 13:47:02 -0400, Walter Bright <newshound1@digitalmars.com> wrote:
>
>> I wrote a brief article which should help:
>>
>> http://www.digitalmars.com/d/2.0/migrate-to-shared.html
>
> Regarding making globals immutable, one other option that was not identified was making it an enum.
>
> Most of the time, I would think you'd want manifest constants versus immutable globals, as they take up no static space.
>
> (not any more comments yet, still reading...)


OK, I think there's another thread talking about this, but I was looking for the same thing...

There doesn't seem to be a way to convert shared data into a form (call it "locked-shared") that then can be used in a function as if it were local data.

For example, given that shared is a type constructor, I have to mark methods on a class shared in order to call them on a shared class instance.  But if there was a way to lock the instance so it temporarly became local, then I could call any method (as long as it didn't squirrel away a pointer to this).  Are there plans to be able to do something like this?  It couldn't be simply marked local, because you don't want to be able to squirrel away a pointer to it.  It would have to be marked something else...

Then comes the notion of deep locking: if you lock simply the this pointer, then it becomes tail-shared as you mentioned -- all the references the object contains are still shared.  You'd almost have to recursively lock everything, and then what if something has a cycle...

I'm thinking this shared thing is going to be only good for small POD, as it's going to be almost untennable to deal with repeating all implementation just because something is shared or not.  And even then, you probably want to copy the POD to non-shared form so you can pass it around.  I don't anticipate anyone making much more than a shared int.

-Steve

Steven Schveighoffer wrote:
> 
> I'm thinking this shared thing is going to be only good for small POD, as it's going to be almost untennable to deal with repeating all implementation just because something is shared or not.  And even then, you probably want to copy the POD to non-shared form so you can pass it around.  I don't anticipate anyone making much more than a shared int.

Personally, I anticipate using shared for large global containers almost exclusively.  I've never considered the "interconnected web of shared objects" idea to be a good one, and building shared into the language doesn't change that.  For containers, a range returned by a shared container will probably have to hold the lock on that container until it is destroyed or shared won't be terribly useful.  I haven't thought about this very thoroughly, but that's my initial take on the idea.