Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:107139 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 58891 invoked from network); 16 Sep 2019 09:52:27 -0000 Received: from unknown (HELO php-smtp3.php.net) (208.43.231.12) by pb1.pair.com with SMTP; 16 Sep 2019 09:52:27 -0000 Received: from php-smtp3.php.net (localhost [127.0.0.1]) by php-smtp3.php.net (Postfix) with ESMTP id 7B98D2CB267 for ; Mon, 16 Sep 2019 00:29:17 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp3.php.net X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Virus: No Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp3.php.net (Postfix) with ESMTPS for ; Mon, 16 Sep 2019 00:29:17 -0700 (PDT) Received: by mail-oi1-x22c.google.com with SMTP id a127so7486973oii.2 for ; Mon, 16 Sep 2019 00:29:17 -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; bh=ypxQig9+PfNQrAgK9rSl6oyjdK37wnSg+eaBkRmVnbE=; b=sHTjNevt6t3eIjg5uVwkJ50gm7UWCaVBQ78yHvDM3ipvlJTUuAkTq4Af4APEBuj7xy JRdoH74Hw8VIk9r+/jiJje9zmEAYktICrR5xeidwtLD+kEBBamVKctD9r4xLoBpEqd+0 lxfrtljg2FfJbszs+BHrKlY4+hpeZE2soJeLC+zFSWROdfNxurbZfzejaNvfo7QT7g4k GHbA1U5HIYLhqiVQnOZfKMZQAH3r8iDzuzUwv4r76EpwAT/tvAJ8DftI6xFhpHxsGVUY W7JfkcwsBa8ddzCMHoRvgiRIGcmDOsYXKD7kogi7iTCC+81FFVrM9pCz55Uzvouoqbt6 yuPg== 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; bh=ypxQig9+PfNQrAgK9rSl6oyjdK37wnSg+eaBkRmVnbE=; b=QLUfc1JN2d//MPISSVsDdkt2ibGFm+AoPZNCvXHDu7o4AdzfxRNGuQtrcnyiwMmEVq 0bbcVSYwfdz30tdtePDkwBEs64bWP2Z9XWyD2dUT2rmk2vkdVbYYQ9hMREXErhcoC91K EIczy5tikEY/PQR4ABpL5dFQfs/xxmR1T2VrY8s8qBHWjrYUg5zvSTFk7e3jc5/HN8Xq Ji7VkTfuVK0vb3GOGHc9fXQNuff4JSfaiTbzhFJiD355jwU1t60cDu1WpH60phOWU7cn cL0tcoV8Pq6UA+3vmjyL0g3cfnPz1XixOEcyl5APmh+mclbhkY04dP1aImmcFksLrnB5 YXTA== X-Gm-Message-State: APjAAAWo3Ud9goc4Qdrj0FUKw6iuI9LuBEGCTXVcclnVIZ2l7IwXQ7Bc /nRntlAODrZsaYEgU2dgiN7RG7dGLVcITlAn53FM9Wqjqu8= X-Google-Smtp-Source: APXvYqyUt/vzvUgj+1QQO85NQU5VfTyF1+XLUYn1DDdSXQ0pCyfDKtMP63xCR8yOvE3Xk49d1FiQHoDE90j2PUXyEEw= X-Received: by 2002:aca:ec06:: with SMTP id k6mr12391950oih.78.1568618954093; Mon, 16 Sep 2019 00:29:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Mon, 16 Sep 2019 09:29:02 +0200 Message-ID: To: PHP Internals List Content-Type: multipart/alternative; boundary="0000000000008bf8e80592a68fdb" X-Envelope-From: Subject: Re: [RFC] Object Initializer From: michal.brzuchalski@gmail.com (=?UTF-8?Q?Micha=C5=82_Brzuchalski?=) --0000000000008bf8e80592a68fdb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, czw., 12 wrz 2019 o 16:00 Micha=C5=82 Brzuchalski napisa=C5=82(a): > Hi internals, > > I'd like to open discussion about RFC: Object Initializer. > > This proposal reduces boilerplate of object instantiation and properties > initialization in case of classes without required constructor arguments = as > a single expression with initializer block. > > https://wiki.php.net/rfc/object-initializer > I'll try to refer to comments proposing other solutions which pop up on this thread in one. Suggested solutions which appeared were: * constructor argument promotion * named arguments While I see them useful in general I don't see them efficient in this specific case. They are not competing features and could live together better suited to different situations. Please be the author for such RFC, I'm looking forward to that. This RFC tries to solve a lot of noise caused by constantly repeating $object-> when assigning properties. Please keep in mind that initializing properties through object initializer applies to visible properties and is possible to assign protected or private properties from the class scope as well. Current RFC was meant to reduce boilerplate especially on DTO|Model classes mimicking "structs" or "data classes" empowering all goods from typed properties. I don't see the reasons why many of you consider public properties a bad solution. PHP language has support for public properties and with typed properties, it is possible to ensure valid object state using VO's which are valid all the time, consider Uuid userland implementation no one checks if that's valid UUID, cause it's ensured by VO. Any kind of features like promoting arguments from the constructor or named arguments are fine but not efficient in those cases. Any good practices suggest limiting function|method arguments while the case is where there is a significant amount of properties to be initialized and additionally which don't need any kind of validation due to VO, or simple scalars. There were also some positive appealing comments, especially like feedback from Benjamin Eberlei. > Using the object initializer would leave the object in a fully consistent state: I am asking myself why didn't include it yet in my RFC. Thank you for the suggestion. I decided to add to proposed RFC that using Object Initializer enforce that if a class is instantiated with the Object Initializer, then at end of the instantiation and properties initialization, all visible (depends on initialization scope) properties are initialized, otherwise a RuntimeException is thrown. This could help with bugs where you add a property to the class, but forget to assign it in all cases where the class is instantiated and initialized. This is described under separate section https://wiki.php.net/rfc/object-initializer#restrictions and mentioned in https://wiki.php.net/rfc/object-initializer#introduction > You should add mention how the Reflection API changes. I would assume both ReflectionClass and ReflectionObject get a new method newInstanceFields(array $fields) with the following behavior: > > $reflectionClass =3D new ReflectionClass(Customer::class); > $customer =3D $reflectionClass->newInstanceFields(['name' =3D> 'Bert']); > // the same as > $customer =3D new Customer {name =3D 'Bert'}; Done. Added in separate section https://wiki.php.net/rfc/object-initializer#reflection To all who considered this RFC missing some benefit, please try to find it in added restriction which likely would help to avoid bugs with uninitialized properties. To all who didn't like the syntax. I can see arguments in favour of the use of "=3D>" instead of "=3D" in initializer block syntax, and would like to propose an additional vote which will help to decide which form fits best. Thanks in advance, Micha=C5=82 Brzuchalski --0000000000008bf8e80592a68fdb--