[interfacekit] Re: BHandler::fToken
- From: Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>
- To: OBOS IK Team <interfacekit@xxxxxxxxxxxxx>
- Date: Fri, 7 Mar 2003 02:33:16 +0100 (MET)
On Thu, 6 Mar 2003, Adi Oanca wrote:
> > I just read through the mails on this and looked through the headers on
> BView
> > and BWindow. It won't be necessary to modify BHandler's token.
>
> Why do you people do not understand what I am saying!
> I NEVER said I want to modify BHandler::fToken.
> I SAID I want to use it! I SAID that I WANTED TO SEE IF IT CAN BE
> MODIFIED!!!
It appeared to me, that when examining this question, you intended to
apply the result, instead of just analyzing this for academical purpose
only.
> > the server will need to send a token for each
> > view added. I haven't figured out the details yet, but this is how it
> should
> > work in general. :)
> >
>
> The reason I've sent that email, was, to ask people if I can use
> BHandler::fToken, because, it already it is a unique identifier; I thought
> we can use it!
I mentioned that already in my previous mail, but let me condense it to a
more compact reasoning again:
BHandler::fToken is unique, but only in the application. That means two
things:
1) Yes, it can be used to identify a BView in the application. BTokenSpace
would be used to get hold of the respective BHandler*, which can be casted
to the BView*. Access to BHandler's private members could be gained by
either making the respective class a friend, or by introducing an adapter
class in the style of BRoster::Private.
2) The handler token cannot be used instead of the server token (only in
addition). The latter one is the means to identify a view uniquely in
the app server.
If an application-local server token -> BView* map was maintained, there
would be no need for using the handler token or (as proposed in my
previous mail) the BView pointer directly. So, this is a design decision
and I couldn't even say, that I would favor any of the approaches. The
pointer idea, if unchecked, is the fastest; with handler tokens one would
reuse an already existing infrstructure; and an additional server token ->
BView* map may be considered the cleanest approach.
In doubt, I would try to keep the impact of the decision local and
postpone the real decision a bit, until the design/implementation has
progressed further and other advantages/disadvantages become apparent.
> FINALLY,
> Forget about this email, I will use BWindow::server_token and
> BView::server_token!
Come on, this attitute isn't really helpful! Misunderstandings and
different opinions can happen, but you're working on a crucial part and
thus discussion is highly appreciated to find good solutions.
CU, Ingo
Other related posts:
