Possible to pass a member function to spawn?
Timon Gehr
timon.gehr at gmx.ch
Tue Feb 7 15:53:57 PST 2012
On 02/08/2012 12:09 AM, Manu wrote:
> On 8 February 2012 00:33, Sean Kelly <sean at invisibleduck.org
> <mailto:sean at invisibleduck.org>> wrote:
>
> On Feb 6, 2012, at 1:38 PM, Oliver Puerto wrote:
>
> > Hello,
> >
> > I'm very new to D. Just started reading "The D programming
> language". I should read it from beginning to end before posting
> questions here. I know ... But I'm just too impatient. The issue
> seems not to be that simple, nevertheless. The code below compiles
> with Visual Studio.
> >
> > I want to have something like my actor class that I can start
> running in it's own thread like in Scala or other languages that
> support actors. So at best, I would like to do something like this:
> >
> > MyActor myActor = new MyActor();
> > auto tid = spawn(&start, &myActor.run());
>
> This should work:
>
> void runActor(shared MyActor a) { (cast(MyActor)a)).run(); }
> MyActor myActor = new MyActor();
> auto tid = spawn(cast(shared MyActor) myActor, &runActor);
>
>
> See, my conclusion is, whenever using this API, you inevitably have dog
> ugly code.
If it is combined with OO.
> That code is barely readable through the casts... I can only
> draw this up to faulty API design.
> I understand the premise of 'shared'-ness that the API is trying to
> assert/guarantee, but the concept is basically broken in the language.
The concept is not broken at all. There are just too few type system
features to conveniently support the concept.
> You can't use this API at all with out these blind casts, which is,
> basically, a hack, and I am yet to see an example of using this API
> 'properly'.
Passing value type and/or immutable messages works well.
> The casts are totally self defeating.
They indicate a potentially unsafe operation.
>
> std.concurrency really should allow unique references to a
> non-shared type to be passed as well, using something similar to
> assumeUnique.
>
>
> Something like that should exist in the language (... or shared should
> just not be broken).
How would you improve usability of the shared qualifier without some
kind of ownership type system?
> Using a template like assumeUnique is no better
> than the ugly cast. What does it offer over a cast?
Nothing. I prefer cast(immutable).
More information about the Digitalmars-d
mailing list