plugins/FeedsNodeProcessor.inc
237:  public function setTargetElement(FeedsSource $source, $target_node, $target_element, $value) {

plugins/FeedsProcessor.inc
1023:  public function setTargetElement(FeedsSource $source, $target_item, $target_element, $value) {

plugins/FeedsTermProcessor.inc
108:  public function setTargetElement(FeedsSource $source, $target_term, $target_element, $value, array $mapping = array()) {

plugins/FeedsUserProcessor.inc
153:  public function setTargetElement(FeedsSource $source, $target_user, $target_element, $value) {

The only call to this I can find passes the $mapping param:

plugins/FeedsProcessor.inc
804:      $this->setTargetElement($source, $target_item, $target, $value, $mapping);

Comments

joachim created an issue. See original summary.

MegaChriz’s picture

MegaChriz CreditAttribution: MegaChriz as a volunteer commented

I think this was done for backwards compatibility. This way processor classes that override the setTargetElement() method that existed before the $mapping parameter was added wouldn't break. Also, not every processor needs the information inside it. But processors that do have a need for the information can access it.

I agree though that the code looks inconsistent and that the availibility of the $mapping parameter looks uncertain, but I'm not sure if it's worth to change it.

The $mapping parameter was added in #860748: Config for mappers?.

MegaChriz’s picture

MegaChriz CreditAttribution: MegaChriz as a volunteer commented
Status: Active » Closed (works as designed)

I think this works as designed. You may reopen this issue if you disagree.