In case it's not clear, I should add that I like the proposal overall. It feels reminiscent of C++ in that you have fine-grained control over the costs of your abstractions but without the overwhelming complexity that C++ brings to the table.
Niko On Nov 8, 2011, at 10:04 AM, Niko Matsakis wrote: >> - The trait/class/interface split, while I think elegant and >> conceptually accurate when it comes to what's often under the covers >> in OO systems, is conceptually *heavy* to users: it makes you think >> an lot about OO-design-theory to write code in. It also carries a >> high engineering cost to implement (pickling across crates, lots >> of logic for simply implementing these abstractions in-crate). >> These costs are the first and main thing on my mind when reading. > > It is certainly possible that the three abstractions will feel ponderous in > practice and I do think this is something to be avoided. In general, I think > having many ways to achieve the same goal in a language is dangerous because > it requires one to mentally choose what design to use. However, I think the > strict dissection of class/iface/trait in this proposal does help in that > regard: when polymorphism is required, you must use an interface. When code > reuse is desired, you must use traits. Otherwise, you can get away with > classes. In other words, there is usually only one way to do it. Ultimately > this does seem hard to judge without using the system. > > One other question is the code evolution path: presumably most users will > start with a class-based design. Adding traits to achieve code reuse is easy > and can be done in a backwards-compatible fashion. Changing a class into an > interface is mostly sound, but for a couple of corner cases: constructors and > fields. I am not so concerned about constructors, but having no way to model > fields in interfaces will result in an annoying round of "search and replace > foo.f with foo.f()". Maybe this is ok, particularly as Rust generally aims > to make costs transparent, and so a field access should never look like a > method call. > > I personally would favor simple properties (e.g., `this.f` desugars into > `this.get_f()` and `this.set_f()` if no field `f` is defined) but these do > hide costs and they also introduce more than one way to do things. > > > Niko > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev > _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
