Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:116844 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 51300 invoked from network); 7 Jan 2022 09:26:04 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 7 Jan 2022 09:26:04 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id BADD6180539 for ; Fri, 7 Jan 2022 02:33:58 -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=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,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-pj1-f54.google.com (mail-pj1-f54.google.com [209.85.216.54]) (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, 7 Jan 2022 02:33:58 -0800 (PST) Received: by mail-pj1-f54.google.com with SMTP id l10-20020a17090a384a00b001b22190e075so11527732pjf.3 for ; Fri, 07 Jan 2022 02:33:58 -0800 (PST) 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=Riv7eyTEquwKGdM4/vXuG+l+9BvDyNYGm0TDkJZeSwI=; b=STbBmW3MXbQosmWdgklW64CAOYnzabeIJbCfWVr9fS96dkDG0lcLPQLcoiIDFqYFm0 GX8Jm/qbgn9zKcg5qk6HiUgmoNcGwd79nXLqOU+q4nzbHX1q42XHLoww5cDSLqaJPWF4 68KS4uAKUjPASurY6/SD3dfAu8Ojs5mCBFGJalj49R1YtMJ7715JHFBwILMKc+qLBFJp DUANZhO9bvVR9VFMfhxaQDp/7hWY5M8xpUhAmjhtLjkrIzP9u72naMKktxIIzfbH0w4D hf3CyFKZqaTxdMbJZEm4bdOXEOP9XZYiJZOp9B2P1SyMRrz6htXH5KKyf4oMgjgRzzZb w+1A== 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=Riv7eyTEquwKGdM4/vXuG+l+9BvDyNYGm0TDkJZeSwI=; b=u4Z/jlCT51VeRbmyyhhvy7+CQbikqNHpvgFAPbMHNJ3M8P81RypDD/bxCHcWFCzuw+ FimovGqky32ZxdP95prMkQVjzmDkedUpgbly4kJzZZcXKDU5BSOl2MioI/1jly5V2Eqj ZMY9OG1dZSSUkerpurGcjEFjB63WZ4oMxXeHXPD+vbtX3kW1KRCqiiUaIIMfLhajGZDR DjyUtHK+zUck3uoBMAlmODYKdiQI+py2f+O+eZOly7AAmWe1Uy0ofT8n5cjZZ8ptaKn2 oifwk+p8jU82kdSi8mo2Uc6anZz464W4mp/JEde92nUeSHHUOc/VR7DLoG4ncwkr36G0 D9yQ== X-Gm-Message-State: AOAM530yUygeWmZHa2yXzLaVN99pQ4j9Ea5cfh8yl+SCFRPmJxlq3/kY yWX24D1h+/H3D9o0f+qLHCDVm5uUPMzZ5+QWpOA= X-Google-Smtp-Source: ABdhPJxCteoh5Fuoq91R/fUri2fVzFA7mZzpw7LA1vBjwu1cNIqd4USKIdS5Nr3r7ZnbT6jZD+7JmUbUOdaJnkTBBUU= X-Received: by 2002:a17:90b:3509:: with SMTP id ls9mr15062092pjb.233.1641551637381; Fri, 07 Jan 2022 02:33:57 -0800 (PST) MIME-Version: 1.0 References: <1641335738.195767637@f174.i.mail.ru> <5a4aebf8-e592-4517-8930-d18b112ef1fd@www.fastmail.com> <5a99809d-afda-546c-5a11-a4f0f821aa37@korulczyk.pl> <6E50C348-9452-40E1-ACE8-06DED11C9136@gmail.com> <9070564d-e138-81f6-c757-812d8962416e@korulczyk.pl> In-Reply-To: Date: Fri, 7 Jan 2022 11:33:46 +0100 Message-ID: To: Rowan Tommins Cc: internals@lists.php.net Content-Type: multipart/alternative; boundary="0000000000003a07ed05d4fb86be" Subject: Re: [PHP-DEV] RFC: Trait expects interface From: landers.robert@gmail.com (Robert Landers) --0000000000003a07ed05d4fb86be Content-Type: text/plain; charset="UTF-8" Hi everyone. I've been lurking for a couple of days, but fwiw, I think this RFC makes more sense as a built-in annotation. Something like #[partialImplemenation(Countable::class)] trait PropertyCount { public function count(): int { return count(get_object_vars($this)); } } Adding new syntax for this doesn't seem like it would provide any useful abilities or optimizations in the language (I could be wrong) but are more useful to developers and tooling. A built-in annotation would allow tooling to introspect the engineer's intentions as well as allow devs to not care, if they want to and/or know what they're doing. I'd actually suggest two annotations: expectsImplementation and partialImplementation. expectsImplementation would mean that it expects those methods from the given class/interface/trait to be present where it is used, while partialImplementation indicates that it implements some (or all) of a child interface/class. Robert Landers Software Engineer Utrecht NL On Fri, Jan 7, 2022 at 10:01 AM Rowan Tommins wrote: > On 06/01/2022 23:53, Robert Korulczyk wrote: > > But there is no easy way to say "`FooTrait::someMethod()` is > > implementation of `FooInterface::someMethod()`" that PHP and SCA will > > understand. And I think this proposal handles this quite well > > > I'm not convinced it does, actually. Consider the following trait: > > trait PropertyCount { > public function count(): int { > return count(get_object_vars($this)); > } > } > > This trait CAN be used to implement the built-in Countable interface, > and it might be useful to label it as such; but does it really make > sense to say that classes MUST implement that interface? > > Even if we put it as a requirement, we can't guarantee that the class > will actually use the trait's implementation of the interface, because > this would still be valid: > > class Foo implements Countable { > private $whatever; > > use PropertyCount { > count as getPropertyCount; > } > > public function count(): int { > return 0; > } > } > > > It feels like this use case would work better with an annotation like > /** @can-implement Countable */ since it is really just documentation > about possible uses. > > Regards, > > -- > Rowan Tommins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > --0000000000003a07ed05d4fb86be--