Small comments: - C++ RTTI is known for being slow, because dynamic_cast has to traverse the inheritance tree to decide whether the requested type is in there. LLVM and I think something else I've seen (V8?) improve on it by having a master enum of class IDs and then just testing whether the object's class ID is between the beginning and end of the list of subclasses of the requested one. As long as this is about performance, I think it would be nice to do that instead of using an implementation people are going to be motivated to replace with custom code anyway. It would require some kind of enum-based syntax to be able to enumerate all the subclasses in one compilation unit, but in my opinion that would be an improvement in some ways. For instance, it would be more sane to implement pattern matching for - maybe not very important for DOM nodes, but perhaps other things.
(While not as commonly faulted, virtual methods themselves are also something of a worst case compared to situations where the compiler might know in superclass X - either because the code was written using pattern matching or because of some slightly fancy magic - that the class is either a Y or a Z, the only two subclasses, and use regular branches with inlining, instead of having to go with a full-blown indirect jump for everything that differs between subclasses.) - Alternately, if a C++-like interface is really the right answer... for the reasons mentioned elsewhere in the thread (orthogonality/more than one way to do it, bad interfaces, and all that), it should still be heavily discouraged. That is, only a small number of projects with pressing performance needs similar to this particular object tree scenario ought to be using it. But in that case, I don't think it's necessary to make it "nice". In fact, I think it should be nasty: if people think like me (...but I don't design serious libraries...), then feature gates requiring one line of code to get past are not going to convince them to rethink their design; they will just bludgeon through them in order to write Java code in Rust. Servo can live with one part of it using nasty macros instead of nice language features. And in C, in my opinion, it's not even particularly nasty even without macros. I appreciate that Rust would need macros to ensure compile-time safety, but it can't be that bad... _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
