> - 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

Reply via email to