Sourcegen rewrite

[maksimil]

With this PR I also want to open a conversation about some topics:

• Is our goal to replace where possible macro calls with sourcegen?
• I think mixin behavior is good, but traits are useful too, because of generalization. If we merge Templates for node initialization #41 we would need SandboxMemberBehavior for build and buildw methods. Or should we add them as mixins too? I mean, we can almost abandon trait if we refuse to use dyn trait objects, which might actually be a valid desicion, since we have moved to enum.

[maksimil]

Also: what did you mean by checklists here. Did you mean milestones or github checklists in issues?

[philip-peterson]

Also: what did you mean by checklists here. Did you mean milestones or github checklists in issues?

I just mean this: I am not a fan of when projects require a checklist to be completed for every PR, because it adds a lot of friction to creating said PR. As such, there's a strict "no checklists required" policy for when PRs are opened in rdom.

Is our goal to replace where possible macro calls with sourcegen?

Unless it's a trivial or one-off macro call, yes. Generally let's try to use sourcegen to generate anything that is reasonably complex.

should we add them as mixins too?

This is a good question. For something that stands on its own like SandboxMemberBehavior, I don't see any reason we can't keep that as a trait. For something like NodeBehavior and ElementBehavior, there was a specific reason we wanted them to not be traits, which is that there's a cost, both in API design (random Result<..., SandboxDroppedError>), and also a small performance hit in following the pointers. It would be interesting to go in the direction of removing the traits for ElementBehavior and NodeBehavior and instead just having a set of methods for node, and a superset of those methods for element.

[philip-peterson]

I would strongly recommend trying to get things working using sourcegen first. It's surely not a perfect tool, but it does have support behind it and is proven to work. Ideally we would spend our time working on the DOM implementation as opposed to tools surrounding it, otherwise we'll spend a bunch of time chasing rabbit holes and won't be able to accomplish the central goal... That said, you're obviously free to work on what you want, I'm just saying it will probably be [a lot 🙂] more productive to work on one thing at a time.

[maksimil]

Agreed

[philip-peterson]

For further context, I have also thought of creating such a tool before. I ended up being woefully disappointed by the state of parsing and stringifying logic in Rust. Syn is simply not where it should be, to support projects like this; I'm pretty sure that's the reason sourcegen has to invoke cargo fmt. Just something to consider as well