Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:109835 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 95503 invoked from network); 24 Apr 2020 17:38:07 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 24 Apr 2020 17:38:07 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 7189E1804E2 for ; Fri, 24 Apr 2020 09:10:19 -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=-1.3 required=5.0 tests=BAYES_00,BODY_8BITS, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS62371 185.70.40.0/24 X-Spam-Virus: No X-Envelope-From: Received: from mail4.protonmail.ch (mail4.protonmail.ch [185.70.40.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Fri, 24 Apr 2020 09:10:18 -0700 (PDT) Date: Fri, 24 Apr 2020 16:10:14 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1587744616; bh=cfVE/s3hKdu/9hJYW6l70ONPlTl61ylizkGa/y6IgM4=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=QoLGAKlsZxVhwLaFla++YiX4koMwqo1mCb3TgaHD68lH44nERusljZqAdoqTGIYWK jIV5InTo5+aGNSZL2zi/c7kO4XBPVoOGcEZC0O90o8VRj+jUk/QoLrC/OQtRyu1trI eecMDs4My1jCeFoogHf+HejahMrf8sJcHcXFwSJI= To: Dan Ackroyd Cc: "internals@lists.php.net" Reply-To: moliata Message-ID: In-Reply-To: <6pYNtxu_0sImXziqQJB6p3nOYx-Dca_fdrTkfvjpHD9XxmWioPFZ01x44xk1n071D-MxZX16_8mEFrzqRVmTgecqDWsxnivqjsiei4KSTbw=@protonmail.com> References: <6pYNtxu_0sImXziqQJB6p3nOYx-Dca_fdrTkfvjpHD9XxmWioPFZ01x44xk1n071D-MxZX16_8mEFrzqRVmTgecqDWsxnivqjsiei4KSTbw=@protonmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] Typed callable properties From: moliata@protonmail.com (moliata) Hello, I would like to correct myself (credits to Marco Pivetta for informing me) regarding union types. While we still wouldn't be able to declare a type al= ias as `callable` and then use it in properties, technically speaking `string|array|object` would allow to pass callables. As such, my point abou= t union types is invalid. Best regards, Benas Seliuginas =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Wednesday, April 22, 2020 7:56 PM, moliata wrot= e: > Hello, > > thank you for your opinion. In response to you mentioning that fixing thi= s > problem would be a huge amount of work, I would like to reiterate the ide= a of > simply ignoring context-dependent problems for the time being. In fact, w= e can > observe this behavior in parameter/return type hints already. As such, it > doesn't make sense to make just property type hints a special case/except= ion. > > Moreover, I oversaw Sara Golemon's comment in the `mixed pseudo type` RFC= that > she would like to use type aliasing and union types instead, at least in = the > long run. The problem that comes up with this approach is that even if we= did > something like this: > `use mixed as string|int|...|callable;` > ...we couldn't apply this `mixed` type alias to properties as callable ty= pe is > not allowed to be used with them. > > Best regards, > Benas Seliuginas > > =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original = Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 > On Wednesday, April 22, 2020 5:29 PM, Dan Ackroyd Danack@basereality.com = wrote: > > > On Tue, 21 Apr 2020 at 14:08, moliata moliata@protonmail.com wrote: > > > > > > > > > > I wanted to ignite a friendly discussion whether > > > PHP should allow typed callable properties. > > > > IMO no. > > Trying to fix the problems with callables would be a huge amount of > > work, and not actually give that much benefit. Even just documenting > > the problems with callables* is a non-trivial amount of work, and I > > suspect there are many horrors lurking with the SPL code related to > > them. > > > > > I believe we should look into... > > > > I'm pretty sure that choosing a different problem to solve that: > > > > - would be easier to solve. > > > > - provide more benefit in the long term. > > > > - not require breaking a lot of userland + internal code immediately, > > but instead allow for migration over a longer period. > > My thoughts on adding 'function types' are here: > > https://github.com/Danack/FunctionTypes/blob/master/function_type_r= fc.md > > There's still more than a couple of known problems that need to be > > worked through, as well as probably unknown problems lurking. As em= ail > > is not a good format for carrying out discussions, if people want t= o > > take part in that discussion, doing it in that repo would be better > > imo. > > Assuming the problems remaining can be addressed, that would give u= s a > > more useful feature, and the existing 'callables' can be slowly > > deprecated and maybe removed from PHP in the distant future. > > cheers > > Dan > > Ack > > *[problems with callables] - https://wiki.php.net/rfc/consistent_ca= llables > >