On Nov 4, 2005, at 12:25 AM, Dr. Adam D. Bradley wrote:
> I've re-worked the name registry to be as un-global-y as possible,
> and would appreciate a sanity check.
> Basically, any module (plugin, app, etc) that needs event name
> resolution has to call csEventNameRegistry::Register(object_reg)
> with a valid iObjectRegistry pointer. After this, they call the
> (static) method csEventNameRegsitry::GetID("whatever.string") and
> are routed to the name registry associated with the current object
> registry (which is also stored using the STATIC_CLASSVAR mechanism).
> class CS_CRYSTALSPACE_EXPORT csEventNameRegistry : public iBase {
> static void Register (iObjectRegistry*);
> CS_CONST_METHOD static csEventID GetID (const char *name);
This seems a bit round-about and also somewhat inconsistent with the
typical CS idiom for "global" objects. It might be simpler and more
idiomatic to create an iEventNameRegistry interface which declares
GetID(), etc., and have csEventNameRegistry implement that interface.
Next, either have csInitializer::CreateEventQueue() also instantiate
a new csEventNameRegistry and place it in the iObjectRegistry, or add
a new csInitializer method to perform this task. Once this is done,
clients can query the object registry for iEventNameRegistry, just as
they would query for iEventQueue or any other "global" object when
needed.
-- ES
My concern with doing it this way is that I've come across a fair number of codepaths that need name resolution (i.e., they use the csevSomething 'symbols') that don't currently have easy access to an iObjectRegistry*, which makes this an even more intrusive and widespread change (although most can be addressed by just adding a private member variable that ges set in their ::Initialize method). I can do it that way (and it does away with the ::Register() nonsense), it's just more time...
Adam
|
-- Adam D. Bradley <[EMAIL PROTECTED]> Boston University Dept. of Computer Science |
signature.asc
Description: This is a digitally signed message part
