• Jason House <jason.james.house gmail.com> Aug 01 2008
• "Steven Schveighoffer" <schveiguy yahoo.com> Aug 01 2008
• Jason House <jason.james.house gmail.com> Aug 01 2008
• Walter Bright <newshound1 digitalmars.com> Aug 01 2008

Jason House <jason.james.house gmail.com> writes:

Walter Bright Wrote:

 Jason House wrote:
 Walter Bright Wrote:
 
 http://www.reddit.com/comments/6u7k0/sharing_in_d/


 This is one of my 3 big wishes for the D language.
 
 The artical talks about shared being transitive just like
 const/invariant. I certainly hope it's more like pure than transitive
 invariant.


 Pure doesn't apply to data types, it applies to functions. I don't know 
 what you mean.



Let's say I have an object that was originally written assuming non-shared
access and contains one member function with no arguments.  Some later coder
comes by and decides it'd be nice to share this object among threads and
creates a shared instance of it.

There's no way to know if calling the member function is safe.  Maybe it
accesses a non-shared global variable.  Maybe a call to an encapsulated
object's member function uses a non-shared global variable.  The maintainer
must be extremely careful and scour the code to ensure there's no accidental
sharing that was not intended.

Maybe I'm reading too much into stuff again, but the article did say "The
proposal is to make accidental sharing impossible".

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

"Jason House" wrote
 Walter Bright Wrote:

 Jason House wrote:
 Walter Bright Wrote:

 http://www.reddit.com/comments/6u7k0/sharing_in_d/


 This is one of my 3 big wishes for the D language.

 The artical talks about shared being transitive just like
 const/invariant. I certainly hope it's more like pure than transitive
 invariant.


 Pure doesn't apply to data types, it applies to functions. I don't know
 what you mean.



 Let's say I have an object that was originally written assuming non-shared 
 access and contains one member function with no arguments.  Some later 
 coder comes by and decides it'd be nice to share this object among threads 
 and creates a shared instance of it.

 There's no way to know if calling the member function is safe.  Maybe it 
 accesses a non-shared global variable.  Maybe a call to an encapsulated 
 object's member function uses a non-shared global variable.  The 
 maintainer must be extremely careful and scour the code to ensure there's 
 no accidental sharing that was not intended.

 Maybe I'm reading too much into stuff again, but the article did say "The 
 proposal is to make accidental sharing impossible".


I have a feeling that the shared/unshared comes with a requriement for 
'shared' functions.  That is, in order to call a function on an object that 
is 'shared', you have to call a function where the 'this' pointer is shared:

class C
{
   shared f(); // can call on a shared C instance, means the 'this' pointer 
is shared
   f(); // can call on an unshared C instance
}

-Steve 

Jason House <jason.james.house gmail.com> writes:

Steven Schveighoffer Wrote:

 "Jason House" wrote
 Walter Bright Wrote:

 Jason House wrote:
 Walter Bright Wrote:

 http://www.reddit.com/comments/6u7k0/sharing_in_d/


 This is one of my 3 big wishes for the D language.

 The artical talks about shared being transitive just like
 const/invariant. I certainly hope it's more like pure than transitive
 invariant.


 Pure doesn't apply to data types, it applies to functions. I don't know
 what you mean.



 Let's say I have an object that was originally written assuming non-shared 
 access and contains one member function with no arguments.  Some later 
 coder comes by and decides it'd be nice to share this object among threads 
 and creates a shared instance of it.

 There's no way to know if calling the member function is safe.  Maybe it 
 accesses a non-shared global variable.  Maybe a call to an encapsulated 
 object's member function uses a non-shared global variable.  The 
 maintainer must be extremely careful and scour the code to ensure there's 
 no accidental sharing that was not intended.

 Maybe I'm reading too much into stuff again, but the article did say "The 
 proposal is to make accidental sharing impossible".


 I have a feeling that the shared/unshared comes with a requriement for 
 'shared' functions.  That is, in order to call a function on an object that 
 is 'shared', you have to call a function where the 'this' pointer is shared:
 
 class C
 {
    shared f(); // can call on a shared C instance, means the 'this' pointer 
 is shared
    f(); // can call on an unshared C instance
 }
 
 -Steve 
 
 


I'd much prefer to discuss the problematic use case and either confirming or
rejecting that D will help protect against it.  Your definition implies that
such programming errors will not be caught.  This seems against the spirit of
the article.

Walter Bright <newshound1 digitalmars.com> writes:

Steven Schveighoffer wrote:
 I have a feeling that the shared/unshared comes with a requriement for 
 'shared' functions.  That is, in order to call a function on an object that 
 is 'shared', you have to call a function where the 'this' pointer is shared:


That's right. Shared objects can only call shared or synchronized methods.