[interfacekit] Re: BLooper::fToken

>Some musings on BLooper's private member varible 'fToken'.  In 
searching 
>a dump of libbe.so, I found a struct/class called 'TokenSpace', which 
>has various member function like 'new_token'.  More intriguing is a 
dump 
>of Dano's version of libbe.so:  there is BPrivate::BTokenSpace, which 
>also has functions like 'NewToken'.  There's more: one version of 
>BTokenSpace::NewToken() takes a pointer to another new class, 
>BPrivate::BDirectMessageTarget.  Only a constructor, destructor and 

Hmm not that I have any certitude I know what I'm talking
about, but this looks like a case of optimization (especially
compared to the one token that is present in BView, which by
contrast might well be a "unique identifier" mandatory type
of thing?),  i.e. something that could be added after the fact
when a first prototype works?   Anyway there will be better knoledge
of what is slow and in need of "speed boosts" once a first realworld
prototype hits the shelves (okay, hits the FTP servers!) i guess.


>While there are common functions in both locations, the fact that 
>app_server exports TokenSpace functions which libbe.so does not leads 
me 
>to believe that libbe.so and app_server each have their own versions of 

>TokenSpace.

Would make sense.. just like BRegion and others, the app_server
was in critical need of some of the code  from libbe.so, whilst
having to enforce the "do not link against libbe.so" magical
rule.. Hopefully none of the cloning attempts will come up
with such a crippling constraint on their own, and there will
be no more "export symbols twice" mess.

Though the two cents i've just written above still do not explain what
those tokens are about, hmm..

Anyway,
HTH
cd.
--
http://cdegea.free.fr/ | BeDev E-16870
"What's oil got to do, got to do with it" -- F02 Chorus

Other related posts: