On 08/11/2011 8:18 AM, Patrick Walton wrote:
Hi everyone,
I've been working on this for quite a while, and I think it's time to
get it out in the open. I tried hard to keep this as minimal as
possible, while addressing the very real issues in expressivity and
developer ergonomics that we have run into with the current Rust object
system. It also tries to preserve the benefits of our current object
system (in particular, the convenience of interfaces).
This has been through several iterations by now, but it should still be
considered a strawman proposal. Feedback is welcome.
I'm still just observing a bit of the action from a distance, but I
thought I'd give a few bits of response:
- Overall: technically strong proposal, but I'm lukewarm about doing it,
and definitely don't want to *now*. In order, I'd prefer to finish
what we've got scoped for the next while, then explore Niko's
sketch, then get to this if we find it necessary.
- If priv {} is class-private, I think this means adding global state to
rust? I'm not sure, but that's what I think 'class private' (vs.
'instance private') means. If so I'd prefer to rethink that.
- The treatments of class vs. @class, copy/send-ability, implied
location in the task heap (vs. exchange), etc. is I think not quite
well enough baked. It's hard. I realize it's hard. But I think it's
a bit too ad-hoc as proposed. It'll surprise users constantly
(including us).
- 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.
- The existing obj system is very specifically there for "flexible
integration of unrelated code". Hence defaulting to the loose-coupled
version of every OO-system device (all-virtual, all-private, ad-hoc
methods as types, no hierarchy). It's as minimal as possible in order
to accomplish that one role, no other. I think it's an important role
since combining not-really-related code in the field is a very common
occurrence.
What you're proposing with 'class' is, IIUC, geared towards people who
really want to write their modules in OO style from the get-go, who
"think" in classes. I recognize this is an existing large audience,
but am ... I guess overall less sympathetic or interested simply due
to my own experience working with systems in OO style: they suffer
from a unique sort of "abstraction spaghetti", where control and
data have been prematurely over-factored, to the point of being hard
to understand. I gather this is my own taste-bias though, and will
try to separate that aesthetic response separate (if possible).
- Given that this doesn't subsume the built-in tycons -- [], {}, tag
don't turn into classes -- I'm more inclined towards initially
exploring Niko's scheme and seeing if we really need an independent
concept of a class. I realize we're not able to factor as
aggressively as we'd like in some cases now; I'm not convinced
taking this cost is the best way to do it.
I realize that, by volume, that's a lot of negative. I'm sorry for that
level of negativity. Let me reiterate that this is a conceptually strong
direction to take an OO system, particularly if you want to encourage
more OO-style coding. My own objections -- beyond the technical
hair-splitting around heaps and private global state - are mostly to do
with "do we want something like that" and "can we afford it".
Philosophical more than technical.
-Graydon
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
