lucy-clownfish

f_Clone_t)cfish_obj_method( self, CFISH_CharBuf_Clone_OFFSET ); return method(self); } Usage: cfish_CharBuf *charbuf = cfish_CharBuf_new(); cfish_CharBuf *clone = CFISH_CharBuf_Clone(charbuf); We had our reasons for going to these extremes: the point of Clownfish was to provide a least-common-denominator object model for bindings to multiple dynamic languages (similar problem domain to SWIG), and the .cfh files also were used to derive types for the binding languages. But there was truly an absurd amount of boilerplate being generated to get around the issue you identify. This is why almost everybody just uses casts to void* for the invocant, skipping type safety. [1] https://github.com/apache/lucy-clownfish

thin which components with very different underlying semantics may cooperate -- it's not a new idea, but neither was AJAX. Other historically significant interoperability initiatives are CORBA, COM, SWIG and GObject." This is why I qualified my post by assuming you were talking about more than these things, because they exist and aren't going anywhere. Fundamentally you can always send a message from a runtime and get a message back in return, but if there's any particular problem with that, it's that it's an oversolved problem rather than a not-solved-enough problem; too many choices! But that is not the fault or responsibility of any one language. "The project I work on, Apache Clownfish (a "symbiotic object system")... Working through issues like how to design an object system which is compatible with diverse GC/allocation schemes is fun and mind-expanding," And I'd point out that a quick glance at your project (which I specify so you can correct me if I'm wrong) makes it appear that I actually already called out all the languages that currently supports (C, Perl, Ruby) [1] as working in the same fundamental regime, before I knew about what you were talking about. It sounds like you're working on those accidental complexities, which may well bring great value to many people (and let me highlight that, I'm serious, this may well be an awesome project, let nothing I'm saying here be construed as a criticism of the project, its ideas, or its worthiness of being worked on!), but is currently working on C-gray to C-gray interop, which, alas, does little to counter the ideas I'm discussing here. If you are interested in these ideas, you may find it worth your time to dig into Haskell/GHC a bit and just consider how you might even begin porting your ideas across. By no means would I suggest actually putting any time to code this in, but it might give you a different perspective to think about. If you are feeling less ambitious, even just looking at how you'd port it to Go, a language still mostly C-gray but with one colorful streak of asynch in it, could be an interesting compare & contrast. [1]: https://github.com/apache/lucy-clownfish/tree/master/runtime