Re: [dev-servo] stylo: Consider spliting gecko bindings (style/gecko_{bindings, string_cache}) into a separate crate / component?

2016-12-15 Thread Xidorn Quan
OK, fair. On Fri, Dec 16, 2016, at 08:14 AM, Bobby Holley wrote: > Given that we've already done the deed and merged the crates, I think we > should hold off on resplitting them until the stylo integration is more > mature. We may find other ways to achieve additional type safety with > tight > co

Re: [dev-servo] stylo: Consider spliting gecko bindings (style/gecko_{bindings, string_cache}) into a separate crate / component?

2016-12-15 Thread Bobby Holley
Given that we've already done the deed and merged the crates, I think we should hold off on resplitting them until the stylo integration is more mature. We may find other ways to achieve additional type safety with tight coupling between generate bindings and other style code (like the ElementData

Re: [dev-servo] stylo: Consider spliting gecko bindings (style/gecko_{bindings, string_cache}) into a separate crate / component?

2016-12-15 Thread Manish Goregaokar
I was actually intending to expand that set as necessary, a lot of the owned and arc types could use this trick too. A lot of this was held back on the Rust compiler losing inline drop flags (which happened recently). I'm okay with splitting it again, but would prefer to avoid as much as possible

Re: [dev-servo] stylo: Consider spliting gecko bindings (style/gecko_{bindings, string_cache}) into a separate crate / component?

2016-12-15 Thread Xidorn Quan
Oh, I see what did you mean. ElementData and AtomicRefCell would be a problem. I don't see anything else, though. - Xidorn On Thu, Dec 15, 2016, at 05:29 PM, Manish Goregaokar wrote: > The sugar stuff is just helpers. The crossover happens in the bindings > file > itself, where &ServoOpaqueType g