Closed geppi closed 1 week ago
Thank you for contributing the new feature. Also, thank you for discovering and fixing the “Multiple Dual Interface” problem in the codebase.
I overlooked it because I had never implemented a COM server that defined a Dual interface.
Before I review the codebase related to safearray
, I have a request for you.
I would like you to submit another PR focused solely on the correction of the record parameter test, separate from this PR. At this point, this patch has many changes in terms of the number of files, and I’m afraid I might overlook something in my review. If you divide the PR by topic, it will be easier to review.
Please divide the commits included in this patch into the following two, cherry-pick the former, and submit a new PR:
source/CppTestSrv/CoComtypesDispIfcParamTests.h
to source/CppTestSrv/CoComtypesDispRecordParamTest.h
test_dispifc_records.py
safearray
functionality
automation.py
CoComtypesDispSafearrayParamTest.cpp
test_dispifc_safearrays.py
I believe that a PR that only makes corrections to the record parameter test can be merged without any problems before this PR.
When you submit a new PR, you do NOT need to close this PR (#569). Rather, I think it would be useful for future maintainers to leave a log on GitHub that you have rebased on or merged to your patch, as the history of the development process.
OK, I'll look into this week after next week.
Thank you for considering splitting this PR. I haven't written much C++ codebase, so I want to keep the granularity of changes I have to review at once as small as possible.
For the Python code part, I think I can do some reviews at this point. So I might make review comments as appropriate, but there’s no need to respond to them until after you submit the new PR and it gets merged.
I've read through the C++ code again.
As previously mentioned, it's likely changing such as CoComtypesDispIfcParamTests
to CoComtypesDispRecordParamTest
will be split off and submitted as a new PR, while adding CoComtypesDispSafearrayParamTest
will remain in this PR.
Now that this COM library has multiple components, changes to UnregisterAll
in CFACTORY.CPP
have become necessary, which were not necessary when there was only a single component.
I think it works even if the library has only a single component. For this kind of codebase, it doesn't problem whether it stays in this patch or is moved to a new PR.
I believe that submitting large PRs is not a problem. I think it's healthy for the community for reviewers and reviewees to interact, dividing the codebase into appropriate sizes to make them easier to merge. On the other hand, there are often cases where it cannot be divided. #535 was just that, even if we separated the GHA workflows and Python code, there were still 2000 lines of C++ code. Even in such cases, the interaction between the reviewer and the reviewee can reduce the cognitive load due to the amount of code changes. Indeed, this was present in #535, which has been merged.
I NEVER say that "if it is not something that can be easily accepted by the reviewer at first glance, you should not PR". That reviewer may be strong in the technical area of that codebase and in good health that day, so they may be able to review hundreds or thousands of lines, or they may not be very familiar with that technical area and want to review as few lines as possible. That is something we don't know until we get feedback for the first time that day.
What's important is whether we can interact to make it easier to merge after submitting the PR. I think that I can interact with you in that way and I am looking forward to it.
If you are unsure, please do not hesitate to consult.
OK, I've separated the name changes for the record parameter testing component in #575.
Rebased on main after #575 was merged.
At the point of 850cedd
_07D2AEE5_1DF8_4D2C_953A_554ADFD25F99_0_1_0.py
ComtypesCppTestSrvLib.py
tagVARIANT._set_value
are revertedThose name changes are fine with me.
So I think this should be ready to be merged now.
With a COM Dual Interface it is possible to get server side changes to SAFEARRAYs marshaled back to the client. However, for a pure IDispatch interface this is currently not implemented.
This pull request adds handling of SAFEARRAYs to the implementation of the automation interface.
A unittest and a new COM test interface for the C++ COM test server are also added.
I have to apologize for a mistake I made in #535. Back at the time I did favor the implementation of several related interfaces in a single component. Unfortunately I didn't realize that this is a problem when the interfaces inherit from the same interface but require different implementations for this interface as is the case for IDispatch (see Multiple Dual Interfaces).
While adding another component to the C++ COM test server was not a big deal, the component naming scheme for which I had advocated in #535 is inadequate for this setup.
So I was wrong and therefore have now also changed the name of the component that implements the interface for record parameter testing to reflect its limited scope.
In the future, adding additional interfaces and components implementing them will be more straight forward.