Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:106786 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 92782 invoked from network); 29 Aug 2019 08:12:36 -0000 Received: from unknown (HELO mail-io1-f67.google.com) (209.85.166.67) by pb1.pair.com with SMTP; 29 Aug 2019 08:12:36 -0000 Received: by mail-io1-f67.google.com with SMTP id u185so672304iod.10 for ; Wed, 28 Aug 2019 22:44:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uY/jWvZI9E16O1APTlFntfTN2G6/nbWyc8CNUTGtOCY=; b=SDG3Qws93/d53tRc6ijbUXvLnJMUlbl4tE9fZQJaN+H9buQvyQjrc/KtBSb+0Rph1/ jvph8SfxP3VS7RoUpgNpQHURLRjPJWLJiXHEVlSrWuz/fqLOYbhlBO1YpNBSO37iQDzi g+hsDSYn0iCsdSVJ+/3s2iF/DAzJ+BsQzKhxuefGTaSqhMSX569vadwOTKIsloiKHJg0 EJD4bUPIBF/pPsdD5K8NqIIOBiMf8I4uiCV2EdiPfqgY1v5ZgbT+60w+aavjKrap6smU ajv/ZZm7O3Qr9U2km/a5zcU0yHgm2gbNLdIgqlvL0HOEL3jbFAG0nhFK+xRpaCgFLSFV GJwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uY/jWvZI9E16O1APTlFntfTN2G6/nbWyc8CNUTGtOCY=; b=QF3ssA/Bo41uRr4ScuTOmqMGVC773yLDK+L1E1nLXHqZcDxglSzduqDS4aSk3hkjr1 l4ZTpQ2MXJOsB/QEgea+LlNf7XhF2lEFu+XcGyNtO2zKoXb8RAiffGF2ftEeor768WhF DO+OkbjgGUdyriPhQOQHUJ5ia+QwzfdILI87XX18ArKk7P9w+lHA2hZTmaLThXJ9AIo8 6p3XN4Gi2gNhfIO+OHi77TBbg+jpMucEcImeglX7eLMcQPQlEPodo50qYWX/kJ/dLy5Z 76G4gj7uznmQLV4UtW0Kf80CstRFCBeq1uol4w8VSvslhm+zh7tHCAyu6kpET/HBBGoe bzTA== X-Gm-Message-State: APjAAAU8ebzq7cr+vMAq801RF7Mcw0R2HqHRIxRe/QIV6SztQAQs4A6a aC1v9PLODkbZZG8bSE9/X3DKrlgqcGGJyxOUfWY= X-Google-Smtp-Source: APXvYqxS4GYE2JOdAlPnRU5mcsUgQun3kAvzLFavD6qllAar4UCbeUE4wKRDwokRpoq8pLkI/kohLrXYHpQkv3IIpvU= X-Received: by 2002:a02:8409:: with SMTP id k9mr8530867jah.122.1567057495332; Wed, 28 Aug 2019 22:44:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Thu, 29 Aug 2019 07:44:43 +0200 Message-ID: To: Benjamin Eberlei Cc: Nicolas Grekas , Steven Wade , PHP Internals List Content-Type: multipart/alternative; boundary="0000000000005a1d2e05913b015a" Subject: Re: [PHP-DEV] Proposal for a RFC From: ocramius@gmail.com (Marco Pivetta) --0000000000005a1d2e05913b015a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey Benjamin, On Thu, Aug 29, 2019, 05:09 Benjamin Eberlei wrote: > > > On Sun, May 5, 2019 at 5:08 PM Nicolas Grekas > wrote: > >> Le sam. 4 mai 2019 =C3=A0 18:37, Marco Pivetta a = =C3=A9crit : >> >> > Hi Steven, >> > >> > As it currently stands, the array cast is the only operation capable o= f >> > exposing object state without triggering any kind of access guards: it >> is >> > very much required for anything that works with reflection and typed >> > properties, and possibly the only operation in PHP that operates on >> state >> > without some contraption intercepting its execution. >> > >> > It is also necessary to distinguish dynamic properties from declared >> object >> > state. >> > >> > For comparison, all of the following have side-effects due to the >> > complexity of the language: >> > >> > * isset() >> > * unset() >> > * property read >> > * property write >> > * ReflectionProperty#getValue() >> > * ReflectionProperty#setValue() >> > >> > Overall, this is problematic, and introduces more magic that I'd gladl= y >> > avoid, in an endpoint used to work around all the engine magic (the on= ly >> > stable one so far). >> > >> > From my end, this sounds like a bad idea, because it removes one of th= e >> > very very few referentially transparent guarantees (if not the only on= e, >> > when dealing with objects) from the language. >> > >> > Greets, >> > >> > Marco >> > >> >> I want to weight in with what Marco expressed. I have the very same >> concerns and they are major ones for many use cases. Mine is VarDumper. >> >> Please don't do this the way it is described. >> > > Because Steve asked for wiki access to work on an RFC for his proposal, I > went back and re-read and just wanted to come in his support as I think i= t > would be a great addition to the existing __magic functionality, > > I want to add a few more arguments why __toArray() should be added > regardless of the objections from Marco & Nicolas: > > 1. PHP already has __debugInfo() which affects the behavior of var_dump() > allowing users to control what gets exposed to it in a debugging context. > This is new magic method would affect Symfony's VarDumper+ VarCloner in a > similar consistent way that gives class owners back control of what gets > exposed. One primary benefit of OOP is encapsulation and guarding against > access of internal state from the outside, so it is questionable anyways > why an idiomatic and simple to use syntax like (array) $object would expo= se > internal state and a developer would have no means of preventing that. > __debugInfo is already arguably added complexity and debugging time for those looking at a dump result and not understanding it. From my PoV, I'd love to also see __debugInfo gone, since it only ever caused me to lose hair. > 2. Adding __toArray would not constitute a backwards compatibility break, > because all existing code does not implement __toArray and would keep the > same exact behavior. > It would break any code relying on current `(array)` semantics against the general `object` type. Can certainly propose it for 8.x, and then we go on a hunt for `(array)` casts, and disallowing them explicitly (cs, static analysis). > 3. You can't argue against the concept of magic methods overall by citing > your own use case that is objectively an extremely magic use of the > existing behavior of (array) $object itself. I can see a very good case t= o > change (array) $object to return only public properties as part of the > general push to cleanup inconsistent behavior in PHP 8. As Nikita > mentioned, it might make sense to add a function that is specifically > designed for your both use-cases instead and that would honestly make thi= s > part of the language cleaner in the end and we can get rid of this * > protected and nullbyte private variable returning behavior once and for a= ll. > It's fine to break this for 8.x, but I think 7.4 already has an added API for this? Can't remember the name, but something about unmangled vars. > 4. ReflectionProperty::getValue() does not trigger a guard clause if you > call setAccessible(true) first, so I don't think the objection that this = is > the only way to access private data is true here. Correct me if I forgot = an > edge case that prevents this. > Guards are triggered for unset properties, even with reflection. > 5. Arguments of API design that toSomethingString() is somehow "better" > than using __toString() and therefore the addition of __toArray() is bad > pit one paradigm (explicit OOP vs magic methods) and should be avoided in > an RFC discussion. We are also not discussing to remove functions in PHP > because we now have classes and methods and this falls into the same > category. Its a subject design decision and shouldn't influence the > expansion of an existing feature/paradigm that one doesn't use themselves= . > I'd say that the paradigm is at the core of the discussion: magic calls are some of the worst traps in the language, leading to monstrous amounts of complexity due to them always being active (rather than being explicitly declared via interface). --0000000000005a1d2e05913b015a--