Hi,
I was looking at the task.rs code [1] and I noticed the getter and
setter for "opts" couldn't help thinking that it is boilerplate code.
Comments removed, the incriminated code looks like this:
enum builder {
builder_({
mut opts: task_opts,
mut gen_body: fn@(+fn~()) -> fn~(),
can_not_copy: option<comm::port<()>>
})
}
fn builder() -> builder {
let body_identity = fn@(+body: fn~()) -> fn~() { body };
builder_({
mut opts: default_task_opts(),
mut gen_body: body_identity,
can_not_copy: none
})
}
fn get_opts(builder: builder) -> task_opts {
builder.opts
}
fn set_opts(builder: builder, opts: task_opts) {
builder.opts = opts;
}
In order to interact with the 'opts' field of the builder, client code
needs to go through get_opts and set_opts which, currently are only
wrappers around "builder.opts" and "builder.opts = opts". This sounds
like boilerplate... but I can hear the Java ghost whispering "but what
if the implementation changes? If you want to add a logger?". The Java
ghost would be right. Well... almost.
If in object declaration it was possible to declare getters and setters,
it would be possible for client code to write "builder.opts" and
"builder.opts = opts" and for the implementor to change the
implementation to getters/setters if necessary. Best of both worlds.
There would be no overhead whatsoever; "builder.opts" and "builder.opts
= opts" would just be syntactic sugar over the accessor, so it can be
made at least as efficient by the compiler than get_opts and set_opts calls.
What do you think?
David
[1]
https://github.com/mozilla/rust/blob/f676547c9788b919762bfb379b1e26ebd94d3dc9/src/libcore/task.rs#L229
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
