[interfacekit] Re: BHandler::fToken

"Marc Flerackers" <mflerackers@xxxxxxxxxx> wrote:
> Why would it contain hackery, why not just a copy of the BMessage 
> class,
> without unneeded functionality=3F This reduces the amount of code to 
> write on
> both sides, and reduces the amount of possible bugs :). Besides 
> flattened
> messages are not such a bad thing, the amount of overhead it would 
> cause is
> highly exaggerated I think.
> For window/view communication a whole other command based system 
> exists, and
> there I find it justified. But for things that arrive as message, and 
> will
> be handled as a message, I think BMessage should be used, unless 
> testing
> shows it's a bottleneck.
> 
> The app=5Fserver messages that arrive on the event port have as magic 
> 'FOB1',
> which shows they're  normal flattened BMessages.

When we are using BMessages (which are itself not expensive, I agree 
with you here), we lose the possibility to bundle several messages 
together and send them once. And there is the real speed bottleneck, 
not in the creation of the message.

Also, there are some things (like BView pointers) that only the BWindow 
knows about (at least, I think so), so it may reduce overhead there as 
well (as creating & flattening on the server, copying, unflattening on 
the client, and then changing, and passing it to the target looks quite 
expensive compared to the app=5Fserver messages).

> > I wondered, how BView/BWindow could get the token of a BHandler, 
> > since
> > neither is a friend of it, but it seems I overlooked the inline 
> > friend
> > function `int32 =5Fget=5Fobject=5Ftoken=5F(const BHandler* )'. BTW, I'd 
> > propose to
> > drop all current friends and introduce a single friend class
> > BHandler::Private (similar to BRoster::Private), which bundles the
> > private member access.
> As long as we can maintain binary compatibility I see no problem with 
> such
> change. Otherwise we can wait until after R1. I think there's quite 
> some API
> cleanup needed once we have an R1.

Yes, that would be nice, even earlier in such cases, but of course, 
only when it's not already implemented (else it steals time ;-))

Adios...
   Axel.

Other related posts: