On 11/8/11 7:04 PM, Niko Matsakis wrote:
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.
Why not go for uniformity and allow virtual fields?
Cheers,
Davud
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
