• Jonas Mminnberg (24/24) Sep 11 2017 I am using the recommended message passing threading model for my
• Adam D. Ruppe (11/21) Sep 13 2017 I would always create a new type and have it hold the data.

Jonas Mminnberg <sasq64 gmail.com> writes:

I am using the recommended message passing threading model for my 
project, and it is not always clear how to do things in the best 
way;

1. receive() pattern matching -- what is common here, always send 
(int, someData) where int is a value you compare to. Or create 
dummy types that you can match on directly?

   receive(int cmd, int[] data) { if(cmd == SomeCommand) 
doStuff(data); }
   receive(SomeCommand, int[] data) { doStuff(data); }

The latter seems nicer, but what's the best way to define those 
types?

Or maybe it's better to be even more general?  Something like;

receive(void delegate(ARGS) f, ARGS a) { f(a); }


2. What is the reason you can't decide which thread(s) to 
receive() from and is there any way around it? Right now I need 
to have a static updateAll() method that is aware of all 
instances and call update() on them as needed. Also it's very 
hard to have generic modules that has their own threads because 
they can receive messages from other modules threads...

3. Is there a recommended way to deal with creating immutable 
data ? Right now I just cast to immutable before returning the 
data since I know I have the only reference, but it would be nice 
to have something like a `UniqueReference` containing a 
immutableMove() method...

Adam D. Ruppe <destructionator gmail.com> writes:

On Monday, 11 September 2017 at 09:56:01 UTC, Jonas Mminnberg
 1. receive() pattern matching -- what is common here, always 
 send (int, someData) where int is a value you compare to. Or 
 create dummy types that you can match on directly?

I would always create a new type and have it hold the data.

struct SomeCommand {
   int[] data;
}

 2. What is the reason you can't decide which thread(s) to 
 receive() from and is there any way around it?

idk the reason but if you are just receiving your custom types 
you shouldn't have to worry about other stuff.

 3. Is there a recommended way to deal with creating immutable 
 data ? Right now I just cast to immutable before returning the 
 data since I know I have the only reference, but it would be 
 nice to have something like a `UniqueReference` containing a 
 immutableMove() method...

There is http://dpldocs.info/assumeUnique which does the cast for 
you but I don't think it can move at all.

You can also create it in a pure function and write to an 
immutable variable when you initialize it.