Jason Orendorff wrote: > In Mozilla 2, we have an opportunity to make major, non-backwards- > compatible changes to XPCOM. What do we actually want to do here? > > bsmedberg wrote about this last December. > > BSBlog: Improving XPCOM for Mozilla 2 > http://benjamin.smedbergs.us/blog/2006-12-22/improving-xpcom-for-mozilla-2/ > > That makes as good a launch point as any. It's time to jump-start > this discussion, because the window for changes is just opening, and > it won't be open forever. > > XPCOM is big, so it might be a good idea to start sub-discussions in > separate threads. For example, I'm going to start a thread about > memory management, pointers, and object lifetimes (you know, AddRef/ > Release, nsCOMPtr, weak references, etc.)
It's best to do some "bottom-up" work on memory management without rocking the whole boat, so that thread is growing and this one is not. But I have a few comments, really about Benjamin's blog post (which is old enough that I'm not assuming he favors everything laid out in it at this point, but still worth reading). The three numbered improvements are good with me (no surprise there) and we're going farther with item 1 (Improve refcounting) in the "future of XPCOM memory management" thread. Item 2, automated conversion to use C++ exceptions instead of nsresults, rotating out parameters back into return values, is also something we're about ready to experiment with, based on Taras's great elsa-based tool work. I hope to hear results soon, in this newsgroup even. Item 3, a better XPCOM binding for JS, is overripe. FUEL and lots of other such things are already sugaring over the sourly-verbose XPConnect bindings for components, classes, interfaces, factories, etc. At this point, could we consider nativizing FUEL instead of inventing yet another "simple XPCOM from JS" API? Ok, say we do, because FUEL does not AFAIK help you to *implement* XPCOM objects in JS. I'm game for more FUEL-ishness, ideally prototyped in JS. The bulleted detailed points after this list of three are less clearly desirable, or I think wrong. We don't want nsISupports <: GCRoot. Do we really want GetInterface from nsIInterfaceRequestor folded into nsISupports, along with QueryInterface? Likewise I'm skeptical about weak ref support -- I do not think that's common enough to warrant being in the top abstract interface, and it falls under the future-of-XPCOM-memory-management thread, where we're thinking in pretty concrete MMgc terms. Querying for nsIClassInfo to get a guaranteed singleton, I buy -- I blogged about that last year in "Fresh XPCOM Thinking". But Benjamin has thought about these and more XPCOM issues harder than I have recently, so I'll shut up now so he can say more. Take this as just my two cents, mostly (modulo the GCRoot and memory management comments). /be _______________________________________________ dev-tech-xpcom mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-xpcom
