Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:116193 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 22265 invoked from network); 3 Oct 2021 12:58:06 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 3 Oct 2021 12:58:06 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 3CBD118053A for ; Sun, 3 Oct 2021 06:42:04 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_20,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sun, 3 Oct 2021 06:42:03 -0700 (PDT) Received: by mail-ed1-f41.google.com with SMTP id b8so19443763edk.2 for ; Sun, 03 Oct 2021 06:42:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dvhU6i/gIDuFSMpwPwIeHPe25wXeH00EL1sqKCGcIRI=; b=C55+PxXkL1YKgRxUrd0mqEh2O6snoCU+d7Bu69YXm7ZHEml10FUwSWQR4pvp1OzsgO HfsiHe3/awg3i9vhlft4/t8VxDoKynEgouSY0jIoKzNlFN8MdlmKKGezY2HwL9pGKhpQ 27qrYF53jok6/f+I9uuuT6kKox8/RCnrRc1kV/Yt/SKQzbC9+7koEWOK8RANbgw/XLNK OTzzebqVJUvCSLGPFMpcPpehfNef0lOHKIpyjPLPn76ayNiTAoIV/3Ptl1BRuBvHBsqJ Po09R2+JNx9AIvbBsp6RTHH5sG3bnrqa91w5hjdKYodM/E7+ptn6XTnin02VzJRs8rTI cYeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dvhU6i/gIDuFSMpwPwIeHPe25wXeH00EL1sqKCGcIRI=; b=ysqaWaFhmUUs2UZ/tOGdurCYdP2P1lBBqRnDgkRhDAvgGZf5AetF0eux53fy+aOOg1 YegE68T36zNIno2qJEcfnPSSO784MXNNOlWF2EAKq+3Z6cxAJKHefTiaIM6VJMLUmmf4 pUTCWKxVIz7oLeA57gL/l3xAHOpNLuFgHvjUU7xqU+SNY5S5VZxfOf5TkJHZg8UgD7+L Pv/36BcMSwcQ+hKao5qmmVZslxnanpd7g/VwBMvmRDDdUfY+cGT0d4qjyNIsKYFgqbab TzDyCjsQpWTzhK3TrFvIvQu8BCSp7fMxKt1k2yvu7GRE8sE/FVLCO8ZFiFKTCyrXAL+G ZzUw== X-Gm-Message-State: AOAM532Mm/y5lMZtMs00hQ3IRrPX3aJkZoZ22UYA+QjNDPwXYeux4AZh RTKtWawWzksiwT70xrlI/ITc6UiExqkeUyE4sTwnM5Amg9lKcQ== X-Google-Smtp-Source: ABdhPJwIjzdQUscvgGg/mXJs7Qkj78owCtMsdNKz2qzsx5e95ISlfeyzbbD4FvajlJgzlqlHH8FAE7KkQgV2GZgyB8s= X-Received: by 2002:a50:e044:: with SMTP id g4mr11229042edl.46.1633268522296; Sun, 03 Oct 2021 06:42:02 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Sun, 3 Oct 2021 14:41:50 +0100 Message-ID: To: Andreas Hennings Cc: PHP internals Content-Type: multipart/alternative; boundary="00000000000018291205cd72f664" Subject: Re: [PHP-DEV] Unified ReflectionType methods From: george.banyard@gmail.com ("G. P. B.") --00000000000018291205cd72f664 Content-Type: text/plain; charset="UTF-8" On Sat, 2 Oct 2021 at 00:54, Andreas Hennings wrote: > Hello list, > I would like to propose new methods for ReflectionType, that would > allow treating ReflectionNamedType and ReflectionUnionType in a > unified way. > This would eliminate the need for if (.. instanceof) in many use cases. > > Some details can still be discussed, e.g. whether 'null' should be > included in builtin type names, whether there should be a canonical > ordering of type names, whether we should use class names as array > keys, etc. > > [...] > > What do you think? > > -- Andreas I don't think this is a good idea, at least in a form like this. I understand that the ReflectionType API is cumbersome but I don't think merging everything together makes a lot of sense. Want does need to know if one is dealing with a Union, Intersection, or single type and conflating the APIs is IMHO a bad idea as it doesn't consider future extensions. And I am not talking about more complex composite types such as (A&B)|C|(X&Y), as those will be handled within the existing design, but potential additions to the type system like function types, literal types, generics, etc. I also don't really understand what the argument for removing instanceof checks is other than more generic code which works, but if this breaks at the next type system addition, this seems rather pointless. Best regards, George P. Banyard --00000000000018291205cd72f664--