Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105692
Return-Path: <stevenwadejr@gmail.com>
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 56521 invoked from network); 13 May 2019 21:49:43 -0000
Received: from unknown (HELO mail-yw1-f68.google.com) (209.85.161.68)
  by pb1.pair.com with SMTP; 13 May 2019 21:49:43 -0000
Received: by mail-yw1-f68.google.com with SMTP id s5so11846723ywd.9
        for <internals@lists.php.net>; Mon, 13 May 2019 11:55:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20161025;
        h=from:message-id:mime-version:subject:date:in-reply-to:cc:to
         :references;
        bh=+xETHPMTRQqYswnLwmhBVJvGep6cZMVeqwRG8bfkBZU=;
        b=J30oGKmS9xR8cJYdshooUrc+H0krHHfIasxyx5TLA/yDSXK5jPgw4dg/5K6UPRdJbQ
         GRH8NBqYVvn6FPns7SovXurBAeYhRRuMtdiVKSVmAFo55H7Yo9R8elPo73iiF3+NquUp
         aNXV3rahNHQrHlxQ2kOmg4r5+4dwmkXX3qGgPqo8r4YWpcUmpsUyMEoNOB8im9Yb7afz
         ceqnWOgrkn82Z5k5rai5Ord3BSuJQ6eDJxXxzRo92rhacKoj/obzoWVD799BeyZWrXpF
         kF+upcdcJJh20jR5U6oqkAu/PmU8GDVy9OCG/QTEY5rqMS4gFKcYqO+aNBfigAje7kec
         i3zw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:from:message-id:mime-version:subject:date
         :in-reply-to:cc:to:references;
        bh=+xETHPMTRQqYswnLwmhBVJvGep6cZMVeqwRG8bfkBZU=;
        b=euh3lrmMxqacDTw45Co3eZm62peHTj/m/KnNQSFeb7gIT+r6ABPwWaja+ZEAtLIPAX
         2np3LDAEfm1W4xUUxVhnoxgudVFvZxRFcDwICKn686eWCX1RhAdzWaVCvRrhA47fUXcU
         fzvZXBEvfpJdgSbS5PWsjqVm6m0MJkx+sdmXAcUXLQ4nwjfSov7UOHrOsqnPHKJny/NU
         /8tJsL1N1RvXvxewbyexpuU/sPs0tK1JUjtNNhwYD0zuk0IITofDbf+lkw6HSGWxJI2M
         8TYVYkbyzD73Dk6zs1dTlKINREtnhZaPGNTHWE1xXVrdAqRdh+qheTic8mEnhphqgEkp
         Qtyg==
X-Gm-Message-State: APjAAAXvDi8cXvXFmg8a0F9tyEVlR7I/Slq99+kRBtZ7R4gCsvOwYt3U
	xkhVTD1VILtVyXp3msxQo4U=
X-Google-Smtp-Source: APXvYqwQAH4glTZsvJ70hSdk+QylxrQDYWJjL/exAy2QbPKJyt1f9WaMSBXk1x+I7yfAtB9z1ZzPKA==
X-Received: by 2002:a81:9a0e:: with SMTP id r14mr14771055ywg.496.1557773710753;
        Mon, 13 May 2019 11:55:10 -0700 (PDT)
Received: from [192.168.86.89] (99-63-227-78.lightspeed.gnvlsc.sbcglobal.net. [99.63.227.78])
        by smtp.gmail.com with ESMTPSA id l18sm1318244ywc.22.2019.05.13.11.55.09
        (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Mon, 13 May 2019 11:55:09 -0700 (PDT)
Message-ID: <898DDEB6-4CC3-44F8-8583-BC3AE22C6928@gmail.com>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_F0741627-01C7-403C-8F0D-F875EB6DFBE3"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Date: Mon, 13 May 2019 14:55:07 -0400
In-Reply-To: <CALKiJKp9J4p-5C6cbZ0kRtO9cT34Nh93LgkcM-yQ137ZOGJ37g@mail.gmail.com>
Cc: Internals <internals@lists.php.net>
To: Rowan Collins <rowan.collins@gmail.com>
References: <FB70FDD7-53AA-4DB4-B747-6E109BE52C2E@gmail.com>
 <1946899E-7EFC-4206-B26D-CD44838315A3@gmail.com>
 <CALKiJKp9J4p-5C6cbZ0kRtO9cT34Nh93LgkcM-yQ137ZOGJ37g@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.104.8)
Subject: Re: [PHP-DEV] Re: Proposal for a RFC
From: stevenwadejr@gmail.com (Steven Wade)

--Apple-Mail=_F0741627-01C7-403C-8F0D-F875EB6DFBE3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

> I'm personally unconvinced of the value of this, and would probably =
propose
> it was blocked by coding standards in my team if it was added, because =
its
> meaning is so ambiguous.

That's perfectly reasonable. Do you also block use of casting to a =
string with (string) $foo as well? I ask because this proposal is simply =
on par with the idea behind string casting for objects.=20

I don't expect that everyone would use custom array casting via =
__toArray(), but for those that would like to have that control and ease =
of use, it'd be valuable for them.

> I actually see quite a lot of classes with normal methods called =
things
> like "toArray", and my comment is always "to *what* array?" Most =
objects do
> not have a single "natural"/"canonical" array representation

I think the same could be said about "__toString()". But with that, some =
classes can be boiled down to a single representation, such as the =
Ramsey\Uuid <https://github.com/ramsey/uuid/> package. The same is with =
arrays. You can have a single entity such as person to where its array =
representation can be first name, last name, age, race, gender, email, =
etc..., or you can have a collection of items, to where in that =
representation as an array, you have control over what information is =
returned and what isn't.

> As a thought experiment, imagine a similar method which allowed you to
> overload (object)$foo. Although (array)$foo tells you slightly more =
than
> that, I'm not convinced it tells you enough that you're not just =
hiding
> meaning behind cute syntax.

I'm confused by example, as there's no real need to overload casting to =
an object as a class is already an object. Whereas, a class is not =
already an array. It's not about "cute syntax", it's honestly about =
providing a simple clutter free helper for developers to take control =
over how their classes are transformed to array representations.

> JsonSerializable actually suffers from similar problems, and is IMO =
useful
> only because it's automatically recursive. I presume the proposed =
mechanism
> would not be, i.e. return [$foo] would not be interpreted as return
> [(array)$foo].

You bring up a good point. Could you for a moment pretend like you're =
behind this proposal and expand upon this question? If PHP were to have =
a __toArray() method, would you see it as being recursive? In your =
opinion, how should/would it react?

I know not everyone will want or use this feature, but for those who =
would, it'd be a great addition IMO. So my goal of this initial thread =
was to see, "what if we had this feature, what would we want it to do?", =
and go from there.

--
Steven Wade
stevenwadejr@gmail.com




--Apple-Mail=_F0741627-01C7-403C-8F0D-F875EB6DFBE3--