ArrayObjectFilter copied each element through the public copy(), whose
first statement resets the object map. That map is what keeps one copy
per source object and what guards against cycles, so an object shared
inside an ArrayObject was duplicated and a graph whose cycle ran through
an ArrayObject recursed until memory ran out.
Reach recursiveCopy() through a bound closure, the way the sibling
SplDoublyLinkedListFilter already does. DeepCopy::copy() is unchanged.
ArrayObjectFilterTest stubbed the copy() call being removed, so it is
rewritten against a real DeepCopy like SplDoublyLinkedListFilterTest,
keeping its flags and iterator-class assertions.
ArrayObjectFilter copied each element through the public copy(), whose
first statement resets the object map. That map is what keeps one copy
per source object and what guards against cycles, so an object shared
inside an ArrayObject was duplicated and a graph whose cycle ran through
an ArrayObject recursed until memory ran out.
Reach recursiveCopy() through a bound closure, the way the sibling
SplDoublyLinkedListFilter already does. DeepCopy::copy() is unchanged.
ArrayObjectFilterTest stubbed the copy() call being removed, so it is
rewritten against a real DeepCopy like SplDoublyLinkedListFilterTest,
keeping its flags and iterator-class assertions.
Since PHP 8.2 a DateInterval created by DateInterval::createFromDateString()
exposes only "from_string" and "date_string" instead of the y/m/d/h/i/s
fields, and "from_string" is ignored when assigned to. Rebuilding such an
interval by copying its visible properties onto a new DateInterval therefore
produced a zero interval, so a copied interval silently stopped shifting
dates.
Read the properties once and rebuild a date-string interval from the string
it was created from, leaving the existing property copy for every other
interval. Cloning would also fix it but would invoke __clone() on userland
DateInterval subclasses, which #76 explicitly rules out.
Since PHP 8.2 a DateInterval created by DateInterval::createFromDateString()
exposes only "from_string" and "date_string" instead of the y/m/d/h/i/s
fields, and "from_string" is ignored when assigned to. Rebuilding such an
interval by copying its visible properties onto a new DateInterval therefore
produced a zero interval, so a copied interval silently stopped shifting
dates.
Read the properties once and rebuild a date-string interval from the string
it was created from, leaving the existing property copy for every other
interval. Cloning would also fix it but would invoke __clone() on userland
DateInterval subclasses, which #76 explicitly rules out.
dualfroz
upstream