Is it correct for me to assume that, even if accepted, virtual things will be behind a feature flag for 1.0? If so, then I think that will be enough friction to cause library authors to favor traits instead, especially if users of virtual-using-libraries would have to turn on the feature flag as well.
On Thu, Mar 13, 2014 at 12:34 AM, comex <com...@gmail.com> wrote: > 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 >
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
