Dissecting the SS

[Georg Wrede]

Kyle Furlong wrote:
 > Walter Bright wrote:
 >> J Duncan wrote:
 >>> also as a big fan of QT, Id like to request a S&S mechanism; or some
 >>> sort of messaging pattern in the language. I think this would take D
 >>> "over the top!"
 >>
 >> While I appreciate and enjoy the enthusiasm, this is deja vu all over
 >> again. My entire career in compilers (C, C++, D, Javascript, etc.)
 >> I've heard people say that "if only you implemented X, it will open
 >> the floodgates!" It never does, but what does work is to work with
 >> people who are *already* D users who are blocked by the lack of
 >> something. With S&S, I'd like to see first how far it can be pushed
 >> with existing D techniques.
 >
 > This last paragraph is why D will succeed. Walter, if this isn't the
 > best way to evolve a language, I don't know what is.

There are a few excellent implementations already announced around here.

Something I haven't seen discussed is whether we should try to make an 
all-encompassing implementation, or maybe separate ones for the 
different situations where they might be used.

A stab at dissecting the field:

The environment where SS might be used might be multithreaded or not, 
the SS bindings might be entirely known at compile time or be dynamic at 
runtime, the participating classes may be known at compile time or only 
at runtime (e.g. plugins?).

That gives potentially eight separate use cases:

000 single thread entirely compile time known bindings and classes
001 multithread
010 bindings known only at runtime
011 multithread & bindings only known at runtime
100 classes only known at runtime
101 multithread & classes only known at runtime
110 both bindings & classes only known at runtime
111 multithread & both bindings & classes only known at runtime

Obviously 111 would be the "top". But even after it is implemented, can 
there be cases where some of the others would suffice and those cases be 
popular enough that implementing them too would be warranted (especially 
for simplicity and performance)?

I've played around a little with QT, but that definitely doesn't make me 
qualified to answer all of these. :-(

Case 000 would be usable (and sufficient) in round robin simulations.

The cases in between, can it be that some of them simply aren't needed? 
Or do people come up with use cases for each one?

---

I'm not seriously suggesting that we implement all 8 separately. But 
after this analysis we might get by with say 3 or 4 that should be 
popular enough to warrant consideration.

And of course, in any of the cases one can always use 111 instead (just 
that it would not be optimal in size and speed for that application).

---

One interesting thing is whether they should really use the same 
invocation syntax? The obvious answer is yes, but if we end up 
implementing only two or three of them (and especially while they're 
still library-only implementations), it may not be imperative at all 
that they'd get invoked alike. For example, if we end up with just 111 
and 000 permanently, then a dissimilar syntax would in time make it 
obvious for the person reading the code which we are using. Knowing this 
might release us from coercing the syntax to be alike, especially if 
their implementations strongly suggest a dissimilar syntax.