This is an archive of the discontinued LLVM Phabricator instance.

[NFC][llvm-libtool-darwin] Encapsulate the process of adding a new member in a class
ClosedPublic

Authored by Roger on Nov 3 2021, 10:41 AM.

Details

Summary

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.

Diff Detail

Event Timeline

Roger requested review of this revision.Nov 3 2021, 10:41 AM
Roger created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptNov 3 2021, 10:41 AM
Roger retitled this revision from [llvm-libtool-darwin] Refactor code to [NFC][llvm-libtool-darwin] Refactor code.Nov 3 2021, 10:52 AM
Roger planned changes to this revision.Nov 3 2021, 11:49 AM

Some tests are failing. Will fix.

Roger requested review of this revision.Nov 3 2021, 12:15 PM

Failing tests appear unrelated to this change. I ran the tests locally and did not see the same failures.

Note that this is in preparation for D113130 (the next diff in the stack).

jhenderson accepted this revision.Nov 4 2021, 1:10 AM

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.

This revision is now accepted and ready to land.Nov 4 2021, 1:10 AM
alexander-shaposhnikov requested changes to this revision.Nov 4 2021, 1:36 AM
alexander-shaposhnikov added inline comments.
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.
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.

This revision now requires changes to proceed.Nov 4 2021, 1:36 AM

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.

Roger retitled this revision from [NFC][llvm-libtool-darwin] Refactor code to [NFC][llvm-libtool-darwin] Encapsulate the process of adding a new member in a class.Nov 5 2021, 10:15 AM
Roger updated this revision to Diff 385162.Nov 5 2021, 12:45 PM

Address some comments.

Roger added inline comments.Nov 5 2021, 12:49 PM
llvm/tools/llvm-libtool-darwin/llvm-libtool-darwin.cpp
312–315

I made the suggested changes in D113215 so that we can maintain the changes in this diff as a "moved from" change.

334–336

I made the suggested changes in D113301 to maintain this change as a whitespace change.

Roger marked 2 inline comments as done.Nov 5 2021, 12:49 PM
Roger added a comment.Nov 5 2021, 12:53 PM

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.

Thanks for pointing that out! I've updated the title.

Roger updated this revision to Diff 385305.Nov 6 2021, 5:10 PM

Rebasing.

Roger updated this revision to Diff 385309.Nov 6 2021, 5:26 PM

Rebasing.

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.
To begin with, this is a class without state, what it does - it saves references to some arguments of the functions but the real mutable state (FileBuffers, MembersPerArchitectureMap) is still exposed, also its usage (lines 467, 468 in llvm-libtool-darwin.cpp) suggests that a function should suffice. The change appears to be somewhat mechanical - the class doesn't introduce a good abstraction, so the new version doesn't seem to be better than the existing code, instead, it appears to be more confusing.

alexander-shaposhnikov requested changes to this revision.Nov 6 2021, 6:52 PM
This revision now requires changes to proceed.Nov 6 2021, 6:52 PM
Roger updated this revision to Diff 385916.Nov 9 2021, 11:57 AM

Try a new approach

Roger planned changes to this revision.Nov 9 2021, 12:05 PM
Roger updated this revision to Diff 385933.Nov 9 2021, 12:26 PM

Add comments

Roger updated this revision to Diff 385936.Nov 9 2021, 12:28 PM

Update comment

Roger planned changes to this revision.Nov 9 2021, 12:54 PM
Roger planned changes to this revision.Nov 9 2021, 2:41 PM
Roger updated this revision to Diff 386300.Nov 10 2021, 1:30 PM

Renaming

Roger planned changes to this revision.Nov 10 2021, 1:39 PM
Roger updated this revision to Diff 386331.Nov 10 2021, 3:05 PM

Formatting

Roger added inline comments.Nov 10 2021, 3:46 PM
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?

smeenai accepted this revision.Dec 1 2021, 2:26 PM

LGTM

This revision was not accepted when it landed; it landed in state Needs Review.Jan 11 2022, 2:50 PM
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.