Current Situation
After implementing issue #2, calling a state generator is complicated by checking whether it accepts a Target or a Target.item as the first parameter.
This was implemented because I thought I need it, but checking 10 of my projects with supposedly the problem described in that issue I see it is not used anywhere.
The assumption formulated in #2 for filters on a Target Path needing to depend on the filters applied on a dependency Path is correct, but with the implementation of Paths, in particular Paths.mappedTo we can cover the requirement without the weirdo runtime type check of the first parameter of the state generator function.
Requirement
Remove the feature introduced in issue #2, in particular:
- Remove the additional type of the
state=parameter to juststr | Callable[[T], str]. - Adapt the documentation on the constructor of
Target. - Remove
_computeStateand useself.generateState(self.item)inline where needed. - Fix tests as needed.
# Current Situation
After implementing issue #2, calling a state generator is complicated by checking whether it accepts a `Target` or a `Target.item` as the first parameter.
This was implemented because I thought I need it, but checking 10 of my projects with supposedly the problem described in that issue I see it is not used anywhere.
The assumption formulated in #2 for filters on a `Target` `Path` needing to depend on the filters applied on a dependency `Path` is correct, but with the implementation of `Paths`, in particular `Paths.mappedTo` we can cover the requirement without the weirdo runtime type check of the first parameter of the state generator function.
# Requirement
Remove the feature introduced in issue #2, in particular:
- Remove the additional type of the `state=` parameter to just `str | Callable[[T], str]`.
- Adapt the documentation on the constructor of `Target`.
- Remove `_computeState` and use `self.generateState(self.item)` inline where needed.
- Fix tests as needed.