You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
But what if we need /bar in one place and /baz in another? We have to do this
$msg/foo/bar -> ...
$msg/foo/baz -> ...
That's not a big deal itself but isn't consistent with "multi-receivers" syntax sugar like this which we have for senders without struct selectors
$msg -> {
a.b
c.d
}
We can do this
$msg/foo/bar -> {
a.b
c.d
}
But we can't do this
$msg -> {
/foo/a.b
/bar/c.d
}
Actually we can implement this but there's two reasons why not to
This syntax isn't obvious
It's not consistent with senders version where we have <SENDER>/<SELECTORS> like a.b/c/d where a.b is sender and /c/d are selectors
This leads as to these options
Have not-consistent syntax
Have only senders sugar
Have only receivers sugar
Re-implement senders sugar so it will be consistent with receivers syntax
Let's start with the number 4 option which would be perfect. The problem is - with senders we want selectors right after port address. Because selection is something that happens after message is sent. With receivers we want selectors before port address because selection is something that happens before final message (struct field) is received.
This leads us to conclusion that we only have 3 options:
Have not-consistent syntax
Have only senders sugar
Have only receivers sugar
Having only receivers (option №3) have benefits over having only senders (option №1) because we can say this
a.c -> {
/foo/ d.e
/baz/ f.g
}
And be consistent because we don't have senders to be inconsistent with.
The problem case is when we send same field to different places:
a.c -> {
/foo/ d.e
/foo/ f.g
}
Option number 1 is possible too if only it won't make grammar complicated
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Right now we have syntax
But what if we need
/bar
in one place and/baz
in another? We have to do thisThat's not a big deal itself but isn't consistent with "multi-receivers" syntax sugar like this which we have for senders without struct selectors
We can do this
But we can't do this
Actually we can implement this but there's two reasons why not to
<SENDER>/<SELECTORS>
likea.b/c/d
wherea.b
is sender and/c/d
are selectorsThis leads as to these options
Let's start with the number 4 option which would be perfect. The problem is - with senders we want selectors right after port address. Because selection is something that happens after message is sent. With receivers we want selectors before port address because selection is something that happens before final message (struct field) is received.
This leads us to conclusion that we only have 3 options:
Having only receivers (option №3) have benefits over having only senders (option №1) because we can say this
And be consistent because we don't have senders to be inconsistent with.
The problem case is when we send same field to different places:
Option number 1 is possible too if only it won't make grammar complicated
Beta Was this translation helpful? Give feedback.
All reactions