On 03/04/2014 10:27 PM, Boris Zbarsky wrote:
On 3/4/14 5:33 PM, Josh Matthews wrote:
I know that some contributors have expressed confusion about the new
JS<T> types that are all over the DOM. I've started a guide to try and
clear up how to use them; please feel free to suggest further topics or
make edits yourself:
https://github.com/mozilla/servo/wiki/JS-smart-pointers

Some more thoughts on casts:

1)  In practice, there are some downcasts that have to be done a lot.
Going from Node to Element is pretty common, as is going from Element to
particular element types.  The simpler these downcasts can be made, the
better.  Gecko actually uses different patterns for those two cases
above.  Casts to element types tend to return null if not castable.  On
the other hand, nsINode::AsElement() will assert IsElement(); callers
are expected to check it unless they know out-of-band that it's true.
This is largely because of API impedance mismatches: we added Element
late, so lots of APIs where the incoming thing is claiming to be a Node
but is actually an Element and everyone knows that.  If you're going to
always check the flag on the cast, you could use the same "return
Option" setup.

2)  Is there a way to make passing a JS<Element> or other Node subclass
to a JS<Node> argument Just Work?  Having to manually cast there is a
bit of a code clutter PITA...

-Boris

I was actually thinking that we could rewrite methods that look like this:

fn TakesANode(node: &JS<Node>)

to read as follows:

fn TakesANode<N: NodeBase>(node: &JS<N>) {
  let node: JS<Node> = NodeCast::from(node);

That would enable passing any Node-derived type as a parameter; unfortunately the cast is still present in the callee, but it could clean up callers a bit.

Cheers,
Josh
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Reply via email to