Prevent access chain updates?

[colinjneville]

I have rust types that are essentially pointers, which are registered and used in rhai scripts. These types have methods and setters that modify state elsewhere in rust-land, but the pointer value itself remains unchanged. Even when these setters and methods are marked pure, access chaining still propagates unneeded sets. In my case, these sets are relatively expensive. I would like to avoid these without requiring users to always assign the pointer to a variable before calling the setter/method. Is this currently possible?

[schungx]

I don't understand. You mean a getters chain?

And you set it at the end?

In that case I can't see how you avoid having to set the values back... Because Rhai would not know that you don't need the new value set back into it. Or to use a temp variable as you suggest.

Unless you can get a reference to the final value at the end of the chain. That's essentially what Rhai does to arrays and maps but that's a built in type.

Since you say the sets are expensive, I suppose that means you have a deep tree of such pointers with arrays and maps and stuff that are excessively cloned when you set even one property.

You can avoid that by making your mutation a method instead of a setter, but that would make the API less ergonomic.

Another alternative is to map your type into Rhai types itself. In fact, any reasonable Rust type can be turned into a Rhai map and array structure that handles such chained updates elegantly.

If all you have is a huge structure of pointers to the actual data, I'd suggest you model that directly with Rhai itself.

[colinjneville]

I don't understand. You mean a getters chain?

And you set it at the end?

Yeah, something like this:

    #[derive(Clone)]
    struct A(B);
    #[derive(Clone)]
    struct B;

    let mut rhai = rhai::Engine::new();
    
    rhai::FuncRegistration::new_getter("b").with_purity(true)
        .register_into_engine(&mut rhai, |a: &mut A| a.0.clone());
    rhai::FuncRegistration::new_setter("b").with_purity(true)
        .register_into_engine(&mut rhai, |a: &mut A, b: B| println!("Expensive!"));
    rhai::FuncRegistration::new("say").with_purity(true)
        .register_into_engine(&mut rhai, |b: &mut B, c: &str| println!("{c}"));
    rhai.register_fn("new_a", || A(B));

    let script = r#"
        let a = new_a();
        a.b.say("Hello, world!");
    "#;

    let _: rhai::Dynamic = rhai.eval(script).unwrap();

In that case I can't see how you avoid having to set the values back... Because Rhai would not know that you don't need the new value set back into it. Or to use a temp variable as you suggest.

Wouldn't the method/setter being pure imply the final value must be unchanged, and therefore doesn't need to be re-assigned?

Since you say the sets are expensive, I suppose that means you have a deep tree of such pointers with arrays and maps and stuff that are excessively cloned when you set even one property.

Sort of, it's actually a system that does automatic change-tracking, so instead of generating one small change at the end of the tree, it also tracks a bunch of redundant changes. More importantly, each change impacts synchronization, so every leaf change does the equivalent of "write-locking" the whole access chain instead of just the final property.

You can avoid that by making your mutation a method instead of a setter, but that would make the API less ergonomic.

Unless I'm doing something wrong (see example code above), I'm still seeing this behavior on pure methods. Changing the getters to methods works though.

I think I should be able to workaround by attempting to call "==" in the setters. If the type has an equality function registered and it returns true, the set can be a noop. Thank you for the help.

[schungx]

Wouldn't the method/setter being pure imply the final value must be unchanged, and therefore doesn't need to be re-assigned?

pure does not have any meaning on a setter, as a "setter" means its value is being "set"...

Also, you cannot mark a setter as pure and stop right there, because there may be non-pure setters up the chain. Then you'd still need to set the new, changed object back.

every leaf change does the equivalent of "write-locking" the whole access chain instead of just the final property.

Rhai already does this locking when you set the leaf so you're safe here. It wouldn't be possible to modify anything along the parents.

I think I should be able to workaround by attempting to call "==" in the setters. If the type has an equality function registered and it returns true, the set can be a noop.

Yup, that would work also. Essentially you swap a set with a compare. If your compare is much cheaper than your set then it makes sense. You can probably hash the values on the way for quick comparisons.