On 7/10/2012 4:15 AM, David Bruant wrote:
I wish that instanciating a character (for a given type) shows the drawCharacter method, but not any of the low-level drawing methods. I don't think it's possible to make Dot and Shape methods module private since Character could be in a different module (maybe I'm wrong, in which case, I'm interested in seeing an example). Character needs these methods to be implemented, but doesn't wish these methods to be provided in its interface.
If it is truly an extension of the shape trait, then it necessarily re-exports them. That's what subtyping means on interfaces: you support the full interface of the supertype.
If you only want to reuse certain implementation routines, don't make them part of the interface. Make them helper functions defined in the module exporting the shape type. They'll be no less privileged than members of the shape trait would be; those can only make self-calls on the shape interface anyways. Various subtypes may use (or not-use) those helpers in implementing themselves, as they see fit.
It feels you're looking for a reason why visibility has to be controlled on a type-internal basis ("protected" vs. "private") rather than a module-basis? I don't (personally) know of any; I think the former is just a different way of denoting the latter. It's still just scoped static access-control. And it too has weird boundary cases that don't quite work right (friend and such).
Why having both classes and traits? Both are mechanisms to enable code reuse. I guess I should restate my question: In which case would I use traits over classes or classes over traits?
Traits can be recombined arbitrarily. Classes can at most just be extended linearly, and at the moment we don't even support that (and may never; it's not clear we'll need it).
-Graydon _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
