<foofighterbar>
Hello. Is there a way I can cause all remaining messages in an actor's mailbox to be dropped?
<foofighterbar>
Initially I had an _accepting_input boolean flag, with an older version of pony. I then had a behavior that conditionally leveraged it:
<foofighterbar>
be foo(i: Input) if _accepting => ...
<foofighterbar>
be foo(i: Input) => ... // not accepting, ignored
<foofighterbar>
but the current version of Pony doesn't support this pattern anymore.
<foofighterbar>
Is there a generally used pattern for this?
aturley has quit [Ping timeout: 252 seconds]
nisanharamati has quit [Quit: Connection closed for inactivity]
foofighterbar has quit [Ping timeout: 245 seconds]
OtakuSenpai has joined #ponylang
dch_ is now known as dch
aturley has joined #ponylang
<vaninwagen>
I think what you describe was possible with case functions, which have been removed, so you dont have no guards
<vaninwagen>
You would have to move it into the body
<vaninwagen>
To really get rid of messages in your inbox you would have to fiddle with some c runtime function
<vaninwagen>
But it would most likely violate some messaging properties pony gives you, and you might shoot yourself in the foot
<vaninwagen>
So moving the guard within the method body is the way to go now
<vaninwagen>
Just a slight syntactical change
OtakuSenpai is now known as name
name is now known as Nawab
<SeanTAllen>
as vaninwagen said foofighterbar, you can still do that, you have to put the "if _accepting" logic in `be foo`.
aturley has quit [Quit: aturley]
aturley has joined #ponylang
aturley has quit [Quit: aturley]
Nawab has quit [Remote host closed the connection]
Nawab has joined #ponylang
endformationage has joined #ponylang
aturley has joined #ponylang
Nawab has quit [Read error: Connection reset by peer]
<vaninwagen>
This matches with another issue you discovered, is my guess
<vaninwagen>
The one with the assert due to the typeparamref
<vaninwagen>
This is actually a good pointer into the right direction, gonna dereference it soonish
<vaninwagen>
^5 endformationage
<endformationage>
vaninwagen: You think it's connected?
<vaninwagen>
In ponyc everything is
<endformationage>
hah!
<vaninwagen>
But this is extra special connected
* vaninwagen
is still guessing, needs proof
<endformationage>
Well, better than having another issue I suppose.
<vaninwagen>
I tested your first example and it occured to me that the typeparam vars (e.g. T) were reported as type names, which seems a bit odd
<endformationage>
This one I think would definately stop me from progressing, however.
<vaninwagen>
Yeah, my hope is to have found one bat to hit two flies at the same time
<endformationage>
Nice.
<endformationage>
Thanks again for looking into all my issues!
<vaninwagen>
I dont have too much time right now, but i'll try to squeeze in as much as possible
<vaninwagen>
Thanks for digging that deep endformationage
<endformationage>
As an asside, I am trying to learn about sub/super-types, upper/lower-bounds. Of course there's not alot written about Pony's gernerics. If I learn about these things, for instance, by reading Scala documentation, does this apply to Pony in the general sense?
<endformationage>
As in, are the concepts of upper/lower bounds, generally applicable?
<vaninwagen>
You'd have to apply the capability subtyping rules, so you get another dimension
<endformationage>
Right.
<vaninwagen>
Tbh i am not 100% super-familiar with these aspects of the type-system myself
<endformationage>
> Thanks for digging that deep
<vaninwagen>
If you find a good explanation of these, feel free to share :)
<endformationage>
.. I'm just trying to build a thing. :)
<vaninwagen>
When i built my thing i was also stumbling a bit. I feel ya
<vaninwagen>
But the learnings were huge
<vaninwagen>
And now i'm tryna fix dem issues just with a wrench and a toothpick