Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:108092 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 21946 invoked from network); 10 Jan 2020 20:13:26 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 10 Jan 2020 20:13:26 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 0C2F11805F6 for ; Fri, 10 Jan 2020 10:19:21 -0800 (PST) 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.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE 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-qv1-f46.google.com (mail-qv1-f46.google.com [209.85.219.46]) (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 ; Fri, 10 Jan 2020 10:19:20 -0800 (PST) Received: by mail-qv1-f46.google.com with SMTP id u1so1147110qvk.13 for ; Fri, 10 Jan 2020 10:19:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dqxtech-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=87f/Q6VZdbHjgEqC4kTe51D2r6kecFVCDeIN7YNSBpc=; b=nOTRN07pyrZ+MDQZRju0ynGNRZQh2s4duXPAvwro0M97eQ6KQ65eJLWnvRN+Pi6Yrn 89PP6+Kr4CPCsMLwIYxuOVFvLWVZr7odi4BWJk9yS8B7uROXsITnxvNEiE/WbXnrWyA6 WoWhXrxQWVZ7705gVeu767maqyk38aZ6eR8WKwXrIr+e8QhJ8DijWZYnHEoO8NXJSaGo rKkrzkoF9ShHSGdiJYvOEPBY5+MLuVDGu9wEyOSdeGQL7DuLz7MCsOYuAkzfrRdbx9cq i8D1pS2u++4F3gsnQoX8KqPaMbqw9VfBACLGKROEg/TCOimL/fP1qJcCMgRlxshaMst5 hjrw== 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=87f/Q6VZdbHjgEqC4kTe51D2r6kecFVCDeIN7YNSBpc=; b=Eh8EjsiDX3hoWHdagx75rbIklmqfRdnGVcX6M1hyyyeHgmAVVoiuDOzxu20xXGIsD5 wnGQyMsSoujPDy1PWNXiKNGbxujlUZ4LLu4ab3xtQAv5hZ3aIx+jlYetBuxrp9invDaU byJnavNVTO5mHRiOm30gJVMtSV5XzEwKAm3iu84Bxlncu/H7MwmMJfXGwTZw9IjqQ5Ng ilnBIo7dQHXdtyD763EFgHwIlrk5grzlOkC7KEozG02+H4QCcaAiu5vCH/N9km1EmHQ3 Dc4IGHxESb9ss3J8y6+T8x49t2hdUDii7PskvFXuXP5IcW0HVlLvxg4qRgkCiQxGmotC vTIA== X-Gm-Message-State: APjAAAWv/h4c/pz6Bja+CafCGjql+dGG1cMuA4+hu3EUl0bvSW1ZLmZn hX3bfwKz0p9gZVy4yxo89BOs8q7NYKs= X-Google-Smtp-Source: APXvYqz2ZPwGUhR2TGS/0DBzdALaephrclH+N8GgV87vn0uzOf5oJ5L0XCYIsn3rccELEbYHUYTUew== X-Received: by 2002:a05:6214:1189:: with SMTP id t9mr3883799qvv.153.1578680357774; Fri, 10 Jan 2020 10:19:17 -0800 (PST) Received: from mail-qk1-f181.google.com (mail-qk1-f181.google.com. [209.85.222.181]) by smtp.googlemail.com with ESMTPSA id e21sm1217881qkm.55.2020.01.10.10.19.16 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 10 Jan 2020 10:19:17 -0800 (PST) Received: by mail-qk1-f181.google.com with SMTP id t129so2698874qke.10 for ; Fri, 10 Jan 2020 10:19:16 -0800 (PST) X-Received: by 2002:a37:e50a:: with SMTP id e10mr4417887qkg.46.1578680356273; Fri, 10 Jan 2020 10:19:16 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Date: Fri, 10 Jan 2020 19:19:05 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Dik Takken Cc: Nikita Popov , Rowan Tommins , php internals Content-Type: multipart/alternative; boundary="000000000000d986c0059bcd29ad" Subject: Re: [PHP-DEV] [RFC] Static return type From: andreas@dqxtech.net (Andreas Hennings) --000000000000d986c0059bcd29ad Content-Type: text/plain; charset="UTF-8" On Thu, 9 Jan 2020 at 20:53, Dik Takken wrote: > On 09-01-2020 17:52, Andreas Hennings wrote: > > On Thu, 9 Jan 2020 at 16:31, Nikita Popov wrote: > > > >> On Thu, Jan 9, 2020 at 4:06 PM Rowan Tommins > >> wrote: > >> > >> An argument could be made that $this does also specify a certain > contract > >> to the caller: That the API may be used fluently or not without change > in > >> functionality. That is > >> > >> $foo->setBar(); > >> $foo->setBaz(); > >> > >> must be strictly equivalent to > >> > >> $foo > >> ->setBar() > >> ->setBaz() > >> ; > >> > >> The same is not the case for a plain "static" type. In fact, I think > that > >> for all other uses of "static" outside of fluent interfaces, not using > the > >> return value would be a programming error. > >> > >> But still, this kind of contract is not a type-system contract, and I'm > not > >> sure it's a good idea to mix other types of API contracts into the type > >> system in this fashion. > >> > > > > We currently don't have another "system" where this kind of info could be > > specified. > > How about: > > public fluent function doWhatever(): static > > Perhaps this could be introduced at some point in the future to enforce > returning $this. > This would work, but: - The ": static" would be redundant if the method is fluid. - I still would find it more natural to look into the return hint and find ": $this". With fluent + static I would have to look in two places. But I was thinking something else related to the ": $this" (or "fluent"). If we already annotate a method as fluent, then the actual "return $this;" statement is redundant as well. We _could_ make this implicit, so you no longer have to write "return $this;". Not sure if that's a good idea, and definitely not in scope of the ": static" proposal. But I think it is useful to have an idea where we want to go with this. > > > And in this case, $this also implies static, so if we would use whichever > > other system to specify $this, the type hint "static" would become > > redundant. > > > > "@return $this" is common in phpdoc (*) since a while, and so far I have > > not seen any problems with it. > > > > If we ask "where does this lead?", one natural next step might be to > > specifically say that the return type is the same type, but NOT $this. > > So, a promise that we really get a new object which we can modify without > > changing the original object. > > > > I don't know how we would express this. Perhaps ": clone", but this would > > be too specific imo, because whether it is a clone is an implementation > > detail. > > Maybe ": new" ? > To me this would not imply that this has to be the same type.. Either way, I think there is no strong enough reason to introduce a syntax for this case. It would be mostly for wither methods, and these can safely return the original object if the entire thing is designed as immutable. > > Regards, > Dik Takken > --000000000000d986c0059bcd29ad--