Add Shl between instance and patch

[yanganto]

Hi @taorepoara,

Could you help to review on this?

[yanganto]

Hi @taorepoara,
Would you might to take a look again? 😄
Thanks in advanced. 🙏

[taorepoara]

I think that a Add between two patches would be nice two !

[yanganto]

Just wonder will << be a better operator than +

pub trait Shl<Rhs = Self> {
    type [Output](https://doc.rust-lang.org/std/ops/trait.Shl.html#associatedtype.Output);

    // Required method
    fn [shl](https://doc.rust-lang.org/std/ops/trait.Shl.html#tymethod.shl)(self, rhs: Rhs) -> Self::[Output](https://doc.rust-lang.org/std/ops/trait.Shl.html#associatedtype.Output);
}

And it will be clear for the user, that the right-hand side always patches on the left-hand side, which can be a patch or an instance.

[taorepoara]

I think that add is better but maybe we should only manage main struc as left operand

[yanganto]

I think that add is better but maybe we should only manage main struc as left operand

That is what I think,

• We remove instance + patch, but provide instance << patch
• We can keep patch + patch with conflict patch field (Some(a), Some(b)) => Some(a + b).
• When doing patch << patch, it will be (Some(a), Some(b)) => Some(b)

It will be straightforward, and I think we do not have a feature for this anymore. Let me implement with an example at the same time.

[yanganto]

We need to check the type inside the macro, else the + operator does not always work here.
https://github.com/taorepoara/struct-patch/blob/8e0b86f6d7a17e8e3846589124f19a220afb9f32/struct-patch-derive/src/lib.rs#L131

The behaviors are not the same, it is replacing without renaming, but merging with renaming
https://github.com/taorepoara/struct-patch/blob/8e0b86f6d7a17e8e3846589124f19a220afb9f32/struct-patch-derive/src/lib.rs#L138

[taorepoara]

We need to check the type inside the macro, else the + operator does not always work here.

Yes it won't work with std types since we can't implement Add for them (or maybe we can ?). A solution for those cases would be to let the possibility to define a function in Patch(add = "...") attribute on fields that overloads the behavior.

The behaviors are not the same, it is replacing without renaming, but merging with renaming

IMO this is the expected behavior, since we want to combine patches, so only there patchable fields.
The field add attribute could be defined on non patchable fields two to overload that behavior.

[yanganto]

Would it be good for a parameter called Patch(addable_fields=...) of the struct or #[patch(addable)] of the field?

At first, I feel let s = S::default() + patch will be a short and clear syntax in this comment.

I agree we can let the happy case go first with this

(Some(a), Some(b)) => panic!("There are conflict patches in {}", stringy(field)).

such that user can do

let new_instance = orig_instance << patch_1 << patch_2;

or

let overall_patch = patch_1 + patch_2;  // the user needs to make sure there is no conflict field
let new_instance = orig_instance << overall_patch;

Do you agree we do this first in this PR, and then, we can discuss which one will be good from Patch(add = "..."), Patch(addable_fields = "..."), and #[patch(addable)] in the next PR?

[taorepoara]

Do you agree we do this first in this PR, and then, we can discuss which one will be good from Patch(add = "..."), Patch(addable_fields = "..."), and #[patch(addable)] in the next PR?

Sounds good to me.

By the way, what I meant with the patch(add = "...") was to let the dev define function to handle the add:

fn my_add_fx(a: SomeThingPatch, b: SomeThingPatch) {
  ...
}

#[derive(Patch)]
struct OtherThing {
  #[patch(add = "my_add_fx"]
  some_thing: SomeThing,
}

[yanganto]

Great, it is complete and will be flexible and extendable for users.
Thanks for your help. I will merge this after #31, and fix the possible conflict in readme. If you still find out something please let me know in the PR. 😄