cxx-qt
cxx-qt copied to clipboard
KDAB
Ensure that all Qt types have a correct default and similar methods
Ensure that our wrapped Qt types have defaults that are the same as Qt and relevant methods (eg getters and setters).
- [ ] Default (potentially using the constructor on the C++ side)
- [ ] Display + Debug (see #131 )
- [ ] Relevant getters and setters
We should also check for which types we can make the members public. QPoint comes to mind. I think in the data-driven design of Rust this might be more idiomatic.
For QUrl we have from_str which needs to be Result<T, E> to match the std trait. At the moment we use Infallible but this could use QUrl::isValid() to return an error if the url is not valid!
Consider if we want by-ref or by-value in various parts of our API.
- Invokable parameters are by ref
- Invokable returns are by value
- Property setters are by ref for non-opaque and by value for opaque
- Property getters are by ref for non-opaque and by value for opaque
- Most of our methods on types take by ref
Related to #58 as well
For Ord and Eq we should be able to make a single C++ template like bool operatorEq(const T& a, const T& b) and reuse the single C++ template for all types like we have with construct and drop etc. (Assuming we can't bind with CXX to the operator of the type)
@vimpostor did you want to continue this issue?
Things that are likely left
- Check relevant types have Default (think most do?)
- Add PartialOrd/Ord to relevant types (again template likely will work well)
- We added
impl AsRef<[u8]>to QByteArray, to assist with using it in general Rust APIs would this, or similar, be useful on any other types? - Consider any other
stdtraits that could be good ?
Member functions is split out into #55 and operators (/ * - +) are in that issue as well, could be a good one after this one.
@vimpostor I've been adding missing member functions in #55 to the types. But I haven't yet done the operators + - / * (note that Rhs will need to be set in some cases for std::ops::Add etc so that it isn't Self), did you want to do these and move them into this issue? As they are likely similar with templates. Or shall i do these as part of #55 ?
And would be good to add Eq i think to the container types, maybe Ord can be skipped for now as discussed.
@ahayzen-kdab Yes, I don't mind adding operator +-/* functions. And I agree, PartEq will make sense for containers, I will tackle that next.
@vimpostor OK! moved the operators onto this issue. Also i noticed in #423 you only did the list types, what about the maps like QHash and QMap ?
- [ ] AsRef
Could you explain what was meant with the last item in that list? Is it solved already?
- [ ] AsRef
Could you explain what was meant with the last item in that list? Is it solved already?
If you look at QByteArray we added this following AsRef implementation as in Rust std APIs AsRef<[u8]> is a common usecase, so it was about checking if any of the other types could benefit from an AsRef as well ? (eg maybe the list/vector but they might be tricky, idk if QString / QUrl or something as well, if there aren't any obvious ones then just mark it as done...)
impl AsRef<[u8]> for QByteArray {
/// Construct a slice of u8 from a QByteArray
fn as_ref(&self) -> &[u8] {
self.as_slice()
}
}
It's possible this is the only useful one, as note things like QString are UTF16 not UTF8 so would need conversions. Maybe only a QVector<T> -> AsRef<[T]> would be useful, but we don't have any slice mechanism in the containers yet and that might be tricky to do. So potentially there aren't any others that are useful and it can be marked as done ?
So potentially there aren't any others that are useful and it can be marked as done ?
Yes, agreed