On Mon, Jul 27, 2009 at 17:28, Luke Kenneth Casson Leighton<l...@lkcl.net> wrote: > On 7/27/09, Brendan Eich <bren...@mozilla.com> wrote: >> XPCOM is self-deprecating. It's excessively costly for both callers and >> implementors of its interfaces, both in runtime overhead and in >> expressiveness restrictions. > > i'd say that that's a price paid for the incredible power and > flexibility of what it brings, but hey, nobody said it would be easy > :) i'm dead impressed that you got XPCOM right, and that it works as > expected, by providing seamless inter-language communication - and now > am a bit puzzled that it's to be deprecated.
Isn't that the same that GObject Introspection brings? You code in whatever language that produces a .so with some metadata, then you can call it from any language with bindings for g-o-i. I would expect Qt has something similar. Regards, Tomeu >> We aren't going to drop it but we are already >> optimizing around it, and removing it in future APIs. > > mmm, history will tell if that's a mistake or not. please don't > remove it _until_ the new API which replaces python-xpcom is fully > completed. that would _definitely_ be a mistake. > >> This doesn't mean multiple programming languages won't be able to call or >> implement those APIs. Cc'ing Benjamin Smedberg, who can say more. > > thanks brendan. > > well, as long as there's _something_ that provides full and complete > python access to the XULrunner DOM model, providing exactly the same > API (all of it and i do mean all of it) as what python-xpcom currently > provides, i honestly don't care how it's done. but i'm still curious. > benjamin? > _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel