Follow-up from comment by @alexpott #3172166-34: Element::properties() produces notices if given an array with integer keys → .
The Element::child() must be the inverse of Element::property() - so let's make this true in code. Element::children() should also follow the same logic.
For Element::child()
public static function child($key) {
- return !isset($key[0]) || $key[0] != '#';
+ return !static::property($key);
}
For "Element::children() we have if (is_int($key) || $key === '' || $key[0] !== '#') { I guess we're inlining this here for performance - which makes sense (up to a point - this stuff is called thousands of times so often the measuring makes it seem way way slower than it actually is). But regardless - we can still make this more efficient by doing if (!(is_string($key) && $key[0] !== '#')). "
"Note the performance arguments for Element::child() don't really hold based on core usage."
Make changes.
Does this also require checking for performance for Element::children()?
None.
None.
None.
Needs work
10.1 ✨
Last updated
Used to track the progress of issues reviewed by the Drupal Needs Review Queue Initiative.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
This issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request → as a guide.
Seems there were failures in last patch.
Even though this is a task will it require a test?