I decided to create a new thread since I was diverging the topic.
Currently, arrays all together with rest of scalar types are value-types
which means when they're passed on (unless passed by a reference) their copies are modified but not the original one.
That's cause object's in PHP are reference types, when passed they're always passed by reference.
Thus making a general ArrayObject class even internally for now should follow value-types semantics.
How do you want to reconcile that?
Excellent point.
Would it not be possible to automatically do a clone on pass when __asArray()===true, such as this:
<?php
function setBar($foo,$newbar) {
$foo->bar = $newbar;
}
class Foo extends ArrayObject {
public $bar;
private $as_array = true;
function __asArray(){
return $this->as_array;
}
function setAsArray($as_array){
$this->as_array = $as_array;
}
}
// PHP 7.x
$foo = new Foo();
$foo->bar = 'baz';
setBar(clone $foo,'bazoom');
echo $foo->bar; // outputs: baz
setBar($foo,'bazoom');
echo $foo->bar; // outputs: bazoom
// PHP 8.x (maybe?)
$foo = new Foo();
$foo->bar = 'baz';
setBar($foo,'bazoom');
echo $foo->bar; // outputs: baz
$foo->setAsArray(false);
setBar($foo,'bazoom');
echo $foo->bar; // outputs: bazoom
Another thing is when shaping an OO API on general array class -> ArrayObject all of the existing array_xxx
functions IMO should be deprecated and that's not likely gonna happen.
Are you saying that ideally we'd have $array->map($callable) instead of array_map($callable,$array)?
Totally agree, but I'd rather have array_map() work with ArrayObject than wait for a "perfect" API that may never come.
If you ask me why I think like that, well if ArrayObject is going to be automatically served from all arrays
keeping array_xxx functions makes no longer a sense, the only thing they could do from that point
is only calling an ArrayObject method, which is different from what they do now they return a new value-type
a new array with filtered, mapped key-value array elements, when working with objects you expect
them to mutate themself if they're mutable or return a brand new instance when they're immutable.
I think it definitely makes sense, because backward compatibility.
We could easily layer a better API on later, assuming opt-in via interface so that no BC would occur.
maybe there is an additional initialization needed besides of key-value pairs only, for eg. additional constructor argument. ... If that happens for internal array_xxx functions it would be hard to guess how to create a new instance,
they'd become a thin wrapper of calling ArrayObject like methods, nothing more.
In the case of userland code extending ArrayObject or its related interfaces could it not simply leverage __clone() if it needs to create a new instance of self to address that concern?
-Mike