Alternative names to `itself` in documentations
Closed this issue · 2 comments
As a complete newbie to both Rust and Rutie I've found it hard to distinguish the 2 different itself
at the examples. (Yes, I know it is a foolish thing. But it made my life harder when I was looking at it for the first time.)
#[macro_use]
extern crate rutie;
use rutie::{Class, Object, RString, VM};
class!(RutieExample);
methods!(
RutieExample,
_itself,
fn pub_reverse(input: RString) -> RString {
let ruby_string = input.
map_err(|e| VM::raise_ex(e) ).
unwrap();
RString::new_utf8(
&ruby_string.
to_string().
chars().
rev().
collect::<String>()
)
}
);
#[allow(non_snake_case)]
#[no_mangle]
pub extern "C" fn Init_rutie_ruby_example() {
Class::new("RutieExample", None).define(|itself| {
itself.def_self("reverse", pub_reverse);
});
}
This pattern repeats throughout the documentation. I'm trying to remember the sensations when I was first looking at those snippets. Basically I was trying to understand how all the pieces interact together and I was not understanding the difference between the example at Custom Rust Objects that doesn't make any use of the methods!
macro and the other examples that use them. It was really hard. Now I'm understanding the basics and think we can easy this for other dumbs like me ;)
In my own code...
The itself
inside the methods!
macro I have renamed to rtself
for conveying that it is a Rutie Object. Now that I understand that this Rutie Object is what can be passed back and forth by the library. (I have also used other things named rt_something to convey the meaning that they are related to this bridge layer (Rutie) where objects come and go from the Ruby VM to the Rust code).
The itself
inside pub extern "C" fn Init_rutie_ruby_example()
I have renamed to klass
as it is the convention for naming instances of classes in Ruby.
What do you think about the current and this proposed naming convention? @danielpclark
Do you have any other suggestion?
I can handle opening a PR for this because it is documentation only thing.
I believe this would be a welcome change. Changing variable names for better clarity is always a welcome change. 👍
Great. I'll make a PR.