On Aug 30, 4:19 pm, Graydon Hoare <[EMAIL PROTECTED]> wrote:
> Dynamic language runtimes can already synthesize their own object
> proxies by inspecting typelibs, and can already walk their own object
> graphs. Many -- perhaps most? -- do user-level "threading" via a central
> event queue. So we may need to ask them for these services, but every
> dynamic language runtime has an API to them. Assuming many dynamic
> language runtimes *need* long term integration with us. [...]
I don't think this recognizes the amount of work involved in something
like PyXPCOM.
It seems to me our choices are:
1) don't try to support multiple language bindings
2) support them in a common way, with common
library code, in a form that might solve
problems for other people too (and thus attract
contributors)
3) support them as we do PyXPCOM and
LiveConnect now, i.e. by ourselves, separately,
and not especially well
I consider #1 a strong option. #2 is pretty nutty. I brought it up
for two reasons. First, #3 is a lot like #2, only without pooling any
effort or designing for pluggability. Under #3, lesser-used languages
(like Python) are unavoidably second-class citizens. They'll never
reflect XPCOM with high fidelity unless someone spends an unlikely
amount of effort on it. My impression is that PyXPCOM is already
lagging and unlikely to catch up, much less keep pace with coming
changes.
Second, I was writing under a hypothetical that assumed PyXPCOM is
something we want to keep and maintain.
> Some dynamic
> languages may just give up and just write compilers to ABC bytecode.
> *Cough* JS *cough*. All the better.
This also seems to underestimate effort. A compiler alone doesn't get
you halfway to, say, Jython.
I'm not convinced we want multi-language support. It's real expensive
and not very useful.
-j
_______________________________________________
dev-tech-xpcom mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-xpcom
