Here we are refactoring the code to encapsulate data into classes. This allows
us to avoid passing the same objects through many functions that don't directly
use them. Now, functions that need to access data can do so from the class
state.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Failing tests appear unrelated to this change. I ran the tests locally and did not see the same failures.
Couple of small suggestions to improve the moved code whilst you're moving it. Otherwise, LGTM, though probably best wait for the later patches to be approved before landing this.
llvm/tools/llvm-libtool-darwin/llvm-libtool-darwin.cpp | ||
---|---|---|
312–315 | I'd probably avoid the "NM" acronym here, as I initially conflated that with the llvm-nm tool for some reason. I'd suggest just calling it NewMemberOrErr and then adding a NewMember variable immediately after the check which is just the dereferenced version, something like the inline edit. The second variable provides a shorter name, and also makes it clear that this has been checked already (since by the time you get to the end of this method, it's quite a long time since you did the check - someone reading the bit in isolation would have to go back and check it). | |
334–336 | You could simplify this to the inline edit. |
llvm/tools/llvm-libtool-darwin/llvm-libtool-darwin.cpp | ||
---|---|---|
305 | not sure this class adds much value, the name "AddMember" doesn't seem to be a good name for a class either. |
Title should also be more specific. "Refactor code" is too generic and doesn't say much about what you are introducing here and why it's needed.
llvm/tools/llvm-libtool-darwin/llvm-libtool-darwin.cpp | ||
---|---|---|
312–315 | I'm sorry, but this class doesn't appear to solve the problem that it declares to solve (encapsulate ... ), that's why I'm opposed to these changes. |
llvm/tools/llvm-libtool-darwin/llvm-libtool-darwin.cpp | ||
---|---|---|
312–315 | I redid the refactoring with your comments in mind. The new MembersBuilder class now completely owns the construction and population of the MembersPerArchitectureMap. That and its memory buffers are stored in MembersData which encapsulates the final output of all the processes of MembersBuilder. Finally, the MembersBuilder class retains the benefit I was going for at the start which was to stop passing around many objects through many functions and just have them accessible as class members. This makes D113130 to be a simpler change :). |
Looks generally fine to me, although I haven't looked in depth. @alexander-shaposhnikov?
not sure this class adds much value, the name "AddMember" doesn't seem to be a good name for a class either.
There are multiple ways how refactor the existing code (but they would require deeper changes than what the current diff does) and clean up the API but this class doesn't seem to introduce a good abstraction.