Trying to make a list of all the examples of extensions to low-level languages for interop into high-level GC’d object models. (New languages and C preprocessor macros don’t count.) Objective-C/C++, Managed C++, C++/CLI, and C++/CX are the big ones. What others?
-
Show this thread
-
(The use case I have in mind here is writing JS/DOM objects in Rust, if it’s not obvious.)
2 replies 0 retweets 10 likesShow this thread -
Replying to @pcwalton
Only other """example""" I can think of right now is good-old XPConnect, but I'm pretty sure that's not what you had in mind. I'd be quite interested to read something comparing these different approaches!
1 reply 0 retweets 0 likes -
Replying to @kneecaw
XPConnect uses an unmodified C/C++ compiler, though, right? (So it doesn’t qualify as a language extension per my definition.)
1 reply 0 retweets 0 likes -
Replying to @pcwalton
For the most part, yes. Though, it does use an IDL, asm stubs, and other codegen glue too. It's more of an abstraction over GC-ed objects to make them look like "native" refcounted objects.
1 reply 0 retweets 0 likes -
You could potentially make something like it sound in rust with the help of some custom derives / attrs? Nastiest part is probably dealing with JS <-> Native <-> JS cycles.
1 reply 0 retweets 0 likes -
Replying to @kneecaw
My current thinking is to do something like Objective-C, where native->JS handles are very rare and explicitly rooted. Most native objects that hold onto JS objects should be JS objects instead.
1 reply 0 retweets 0 likes -
The more I look into Objective-C the more I realize its design is brilliant—native->managed is nasty, so the entire ecosystem discourages it. As an example, people just don’t put Objective-C objects in C containers and use NSArray instead.
1 reply 0 retweets 1 like -
Replying to @pcwalton
That seems fairly reasonable, assuming you can get good enough ergonomics. You wouldn't want to have to explicitly downcast from an untyped JSValue every time you access a private array member for example.
2 replies 0 retweets 1 like -
I suppose you'd then use a custom attribute to allow describing JS slot layouts with rust-style struct decls, and the rust type system to describe rust-generated JS objects?
1 reply 0 retweets 0 likes
Yep. They’d “look like” Rust objects syntactically. This is basically what C++/CLI does: .NET objects “look like” C++ objects, though they’re very different and have a special pointer sigil (Foo ^ instead of Foo &/Foo *).
-
-
Replying to @pcwalton
It's sorta like a reverse-XPConnect, I suppose. XPConnect makes JS objects "look like" C++/Rust objects (by wrapping them with a refcount), while the proposed approach approach makes Rust objects "look like" JS objects (by storing fields as slots).
1 reply 0 retweets 1 like -
I proposed a similar-ish idea at one point or another for C++, but as we can't inject compiler extensions easily, it'd have to be done in a separate codegen pass, like how we do XPIDL today.
1 reply 0 retweets 1 like - 4 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.