Hi, It sounds to me like *properties* => http://en.wikipedia.org/wiki/Property_%28programming%29
*A property, in some object-oriented<http://en.wikipedia.org/wiki/Object-oriented_programming> programming languages <http://en.wikipedia.org/wiki/Programming_language>, is a special sort of class <http://en.wikipedia.org/wiki/Class_%28computer_science%29>member, intermediate between a field <http://en.wikipedia.org/wiki/Field_%28computer_science%29> (or data member <http://en.wikipedia.org/wiki/Data_member>) and a method<http://en.wikipedia.org/wiki/Method_%28computer_science%29>. Properties are read and written like fields, but property reads and writes are (usually) translated to get and set method calls.* Is this what you wanted to express ? -- Matthieu On Sat, Jul 21, 2012 at 8:54 PM, David Bruant <[email protected]> wrote: > 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 >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
