Closed tisonkun closed 1 month ago
The only wart I found is that #[map]
implements From and Into both on TablePropsExposed
. So there is no From<TablePropsExposed> for TableProps
implemented for TableProps
.
For all where I previously write TableProps::from(props /* TablePropsExposed */)
I should now write props.into()
. But this is a reasonable trade-off.
Hi! Thank you for good words!
The only wart I found is that
#[map]
implements From and Into both onTablePropsExposed
. So there is noFrom<TablePropsExposed> for TableProps
implemented forTableProps
.
That was deliberate. I think in this case, it is more intuitive when, if a proc macro is applied on struct A
, it produces impl ... for A
.
As an alternative, instead of applying map_owned
on one side, you can apply 'from_owned' on both sides:
#[derive(Debug, Clone, PartialEq, Eq, Deserialize, o2o::o2o)]
#[from_owned(TablePropsExposed)]
pub struct TableProps { ... }
#[derive(Serialize, Deserialize, o2o::o2o)]
#[from_owned(TableProps)]
pub struct TablePropsExposed { ... }
It is wordier, but in some cases may even result in more readable code.
Please reopen if you have any other questions or suggestions.
Works perfectly so far.
I may have some further ideas like use mapstruct to keep fields update in sync. But with
o2o
the compiler can guard the convert bound. And I'd like a replacement forderivative
which seems to be unmaintained but its current code works well. educe is weird and drive_more doesn't support PartialEq. Anyway, these seems out of the scope of this crate. Just share some related thoughts.Thanks for this excellent crate. I'll adopt it further if it reaches 1.0 and stable API with considered.