[haiku-development] Re: R1/a4 initial planning

  • From: Stephan Aßmus <superstippi@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Fri, 24 Feb 2012 13:33:47 +0100

Hi,

Am 23.02.2012 22:16, schrieb Ingo Weinhold:
Axel Dörfler wrote:
When it comes to slots and signals, though, I don't particularly like
them, and I wouldn't want to have that in an R2 API at all. That concept
doesn't play well with C++, and 'moc' is really annoying if you ask me.
Why not choose a language that has support for those concepts in the
first place (like Objective-C IIRC)?

No clue, maybe they liked templates, too? So far I've experienced the 
limitations of moc only as minor nuisance (things like having to pull out an 
inner class to be able to use signals/slots or having to create a base class 
for a template class). And you can say what you want about them, using signals 
and slots results in less code than an equivalent implementation with BMessages 
on Haiku.

For the WebKit port, I was faced with the situation that WebCore contained asserts that certain stuff was executed on the main thread. This forced me to, instead of locking the BApplication and calling some method, actually send it a BMessage instead, so that in the BApplication thread, I could decompose the BMessage and then call whatever WebCore method it was I needed to call in the first place.

This is significantly more code, and error prone, than using signals and slots where emiting a signal invokes the respective slot of another QObject automatically in the correct thread.

Best regards,
-Stephan

Other related posts: