On 7/26/13 8:54 AM, Michael Woerister wrote:
To me this seems very much like a slightly clunky way of emulating inheritance (with a lot more typing involved at definition and usage sites). Field accessor functions or traits can alleviate some of this clunkyness at the usage site; however, at the cost of even more boilerplate needed at the definition site:pub enum decl { decl_local(@Local, span), decl_item(@item, span), } impl decl { fn get_span(&self) { // this match statement also introduces some unnecessary runtime overhead... match *self { decl_local(_, span) => span, decl_item(_, span) => span } } } This situation is not very satisfactory but I don't know an easy solution to the problem. I certainly don't suggest adding such a heavy tool as inheritance to Rust just for this use case.
This is the preferred method of emulating common fields. We use this in Servo.
I would like to add an optimization to remove the unnecessary runtime overhead in this case. In theory this should be amenable to compiler optimizations.
So for now I'll keep adapting things to the new naming convention but I'll leave wrapped enums as they are. I'm very much interested in any comments regarding this problem of types with some common fields and some specialized fields. Type specialization is something popping up all the time and Rust seems to have some weak spots there. Some concrete style questions: - Do enum variants follow the guideline for variable_naming or TypeNaming. (Although, imo enum variants should be *subtypes* of their defining enum anyway ;)
TypeNaming, i.e. CamelCase.
- What is the preferred naming convention for getter functions such as `get_span()` above? get_span()? just span()? something else?
Just `span()`. There's no need to use a `get` prefix in Rust because method calls and field projections are syntactically distinguished.
Patrick _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
