On Feb 24, 2010, at 12:29 AM, Igor Lesik wrote:

> Sean, I think your implementation of receive() has some imperfections, which I fixed and it works now all right.
> 
>> Most importantly, this still doesn't work: receive( (int a) {}, (string b) {} );
>> The compiler still "sticks" on the type of the first delegate in the foreach ...
> That is very true, but we can iterate over T instead of ops, which is even better idea.
> 
>> Once this is fixed I'll add checking for overload conflicts in the receive set, etc.
> "receive( (int a) {}, (string b) {} );" works now, we can continue

Okay, I checked in the first cut of this module.  It still lacks receiveTimeout and receiveOnly, but plain old send/receive are in place.  I'll see about improving it over then next N days.

>Okay, I checked in the first cut of this module.? It still lacks receiveTimeout and receiveOnly, but plain old send/receive are in place.? I'll see about >improving it over then next N days.

Excellent, thanks.

Please, consider an idea to check if first parameter of receive() is not delegate but integral and treat it as timeout value. It makes both receiveTImeout() and receiveOnly() one liners.

On Mar 9, 2010, at 1:49 AM, Igor Lesik wrote:

>> Okay, I checked in the first cut of this module.  It still lacks receiveTimeout and receiveOnly, but plain old send/receive are in place.  I'll see about >improving it over then next N days.
> 
> Excellent, thanks.
> 
> Please, consider an idea to check if first parameter of receive() is not delegate but integral and treat it as timeout value. It makes both receiveTImeout() and receiveOnly() one liners.

Will do.

By the way, I've been thinking about receive((int x) {}, (Variant x) {}) and I wonder if rather than testing the first element in the queue and having the Variant delegate getting the value if it's not an int, that the correct behavior should perhaps be to search the entire queue for an int and if there aren't any then take the first element and give it to the Variant.  I suppose it would be easy enough for the user to imitate with two consecutive receives, the first having a 0 timeout though.

>By the way, I've been thinking about receive((int x) {}, (Variant x) {}) and I wonder if rather than testing the first element in the queue and having the Variant delegate getting the value if it's not an int, that the correct behavior should perhaps be to search the entire queue for an int and if there aren't any then take the first element and give it to the Variant.

Consider receive((int x){},(string s){}), first element in the queue is string, do you search for int in the whole queue in this case? No, you search for a handler for string. Case receive((int x) {}, (Variant x) {}) is not (and should not be) different. With what you propose user will experience very non deterministic behavior with messages processed completely out of order; consider long queue [var, string, ..., int] with int at end, why on earth user wants last element in the queue to be handled first?

Plus it will mess up msg priorities, in case we implement them one day.

On Mar 9, 2010, at 9:50 AM, Igor Lesik wrote:

>> By the way, I've been thinking about receive((int x) {}, (Variant x) {}) and I wonder if rather than testing the first element in the queue and having the Variant delegate getting the value if it's not an int, that the correct behavior should perhaps be to search the entire queue for an int and if there aren't any then take the first element and give it to the Variant.
> 
> Consider receive((int x){},(string s){}), first element in the queue is string, do you search for int in the whole queue in this case? No, you search for a handler for string. Case receive((int x) {}, (Variant x) {}) is not (and should not be) different. With what you propose user will experience very non deterministic behavior with messages processed completely out of order; consider long queue [var, string, ..., int] with int at end, why on earth user wants last element in the queue to be handled first?
> 
> Plus it will mess up msg priorities, in case we implement them one day.

Yeah, it was just and idle thought.