Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DM-21333: Implement afw.image.Filter replacement(s) #543

Merged
merged 9 commits into from Oct 28, 2020

Conversation

kfindeisen
Copy link
Member

This PR implements the FilterLabel class and unit-tests its functionality. Integration with Exposure is not yet supported, and will be added later.

Copy link

@andy-slac andy-slac left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, few comments/questions. I'm not very familiar with afw persistency mechanism but I see that tests cover everything.

include/lsst/afw/image/FilterLabel.h Show resolved Hide resolved
Comment on lines +136 to +141
// A separate boolean leads to easier implementations (at the cost of more
// memory) than a unique_ptr<string>.
// _band and _physical are part of the object state iff _hasBand and _hasPhysical, respectively
bool _hasBand, _hasPhysical;
std::string _band, _physical;

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just for my education - I presume that label cannot be empty for actual physical/band, would it simplify things if you use empty string instead of separate bool flag for each?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While I can't think of a legitimate use for an actual empty string as either name, I distrust magic values. This approach leads to less surprising behavior, I think.

include/lsst/afw/image/FilterLabel.h Outdated Show resolved Hide resolved

#ifndef DOXYGEN
class FilterLabel;
namespace impl {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think people usually use detail namespace for implementation-level global names.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The developer guide said to use impl in this case.

src/image/FilterLabel.cc Outdated Show resolved Hide resolved
src/image/FilterLabel.cc Outdated Show resolved Hide resolved
src/image/FilterLabel.cc Outdated Show resolved Hide resolved
src/image/FilterLabel.cc Outdated Show resolved Hide resolved
src/image/FilterLabel.cc Outdated Show resolved Hide resolved
tests/test_filterLabel.py Show resolved Hide resolved
This class has factory methods and getters, but no other functionality.
Though in principle these could be tested separately, doing so would
greatly increase the proportion of tests that use factories instead
of keyword for construction, and I want to encourage the latter as
the natural Python interface.
Since FilterLabel is a value-like object, all four methods
are appropriate. Hashing is non-trivial because some members are
part of the object state only some of the time; I've added a
C++ unit test to check this.
@kfindeisen kfindeisen merged commit 7b7d0ee into master Oct 28, 2020
@kfindeisen kfindeisen deleted the tickets/DM-21333 branch October 28, 2020 16:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants