Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107823
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_9112A57D-CCA7-48A5-B41A-E117D2D0DADD"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Message-ID: <6A47C8D5-FDCA-45DA-9BC3-DC9417FEE36E@newclarity.net>
Date: Mon, 18 Nov 2019 13:23:03 -0500
To: PHP internals <internals@lists.php.net>,
 =?utf-8?Q?Micha=C5=82_Brzuchalski?= <michal.brzuchalski@gmail.com>
Subject: Enabling ArrayObject et.al. to fully replace array usage
From: mike@newclarity.net (Mike Schinkel)

--Apple-Mail=_9112A57D-CCA7-48A5-B41A-E117D2D0DADD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I decided to create a new thread since I was diverging the topic.


> On Nov 18, 2019, at 5:36 AM, Micha=C5=82 Brzuchalski =
<michal.brzuchalski@gmail.com> wrote:
> 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.=20
> Thus making a general ArrayObject class even internally for now should =
follow value-types semantics.=20
> How do you want to reconcile that?

Excellent point.

Would it not be possible to automatically do a clone on pass when =
__asArray()=3D=3D=3Dtrue, such as this:=20

<?php

function setBar($foo,$newbar) {
   $foo->bar =3D $newbar;
}

class Foo extends ArrayObject {
   public $bar;
   private $as_array =3D true;
   function __asArray(){
      return $this->as_array;      =20
   }
   function setAsArray($as_array){
      $this->as_array =3D $as_array;
   }
}

// PHP 7.x
$foo =3D new Foo();
$foo->bar =3D 'baz';
setBar(clone $foo,'bazoom');
echo $foo->bar;             // outputs: baz
setBar($foo,'bazoom');
echo $foo->bar;             // outputs: bazoom

// PHP 8.x (maybe?)
$foo =3D new Foo();
$foo->bar =3D '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=20
> 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=

--Apple-Mail=_9112A57D-CCA7-48A5-B41A-E117D2D0DADD--