On Sat, 25 Feb 2012 08:53:02 +1300, Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> wrote:
don't have their uses, only that they are alien to C++, and I would rather choose a language that suits my needs than to hack features into it this way. If they were a genuine language feature, they could even be quite elegant, but the way it's done spoils it a bit for me.
whats about language binding when using special language features e.q. of ObjectC? Not sure but that could cause some trouble.
What is crucial for a future api is a api that soften the team boundary. A team could be seen just as another, special, thread. This is handy for e.g. sandboxing. The BeApi already support that! a message could be send everywhere, we should definitely not drop that. BeShare also uses BMessage over the network this carries the idea further on. However, signal/slot are IMHO just easier to use. Because they are generated using moc, signal/slots code for IPC or network communication could be generated as well.
Definitely want to see such a system but maybe Qt just as a c++ backend.
And, for common use cases, I find BMessages generally more useful/versatile.
Similar to what Ingo said just define a signal/slot with a BMessage argument. Btw. the BeAPI hook functions can be seen as kind of signal/slot connections (BMessage -> method call).
Regards,
Clemens
