Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:127008 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id 6829E1A00BC for ; Tue, 1 Apr 2025 11:49:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1743508015; bh=YQFZrAjPSyZJeoC6y3bR1+73GGpzYaR1wZxYfHb0PWc=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=AnYlTeMiW1YLbFnZDQKb4jdikXsgl6ymmZSYYFCk+UozokDIpSUGKkzAujfDyvRig jCxWpB12FXXTA0SDknwjjkCahNI13Gzq22O9ahQjE91mIsJgaeZHGyx3xszhBc/FTu i6dQaGfA21v8mB1ZJ7pIxhZmjSRUDDoeRQJtbVCT4zIL70qZilA+TliUPZ9Y9xYKo1 IltvctVrbLrY/nNXlaK6MHmd0SYSuwbdThTLdeK5tCCPOysk5pMAfMfaTFIO+YWcLu Ydbo9rzEUlkMXMEw47xnSH6BwgIIoPQ06N0Tu2IyfofUDshXFgtz4ZR3fL/05GbKON cbtNntole/7tQ== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 72E5A180088 for ; Tue, 1 Apr 2025 11:46:54 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,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=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from mail-ej1-f41.google.com (mail-ej1-f41.google.com [209.85.218.41]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 1 Apr 2025 11:46:51 +0000 (UTC) Received: by mail-ej1-f41.google.com with SMTP id a640c23a62f3a-aaecf50578eso944408866b.2 for ; Tue, 01 Apr 2025 04:49:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743508157; x=1744112957; darn=lists.php.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=YQFZrAjPSyZJeoC6y3bR1+73GGpzYaR1wZxYfHb0PWc=; b=i4DnnCB6EuOe2X7WQu7vQejD+FIpPw6X4SYU/4gjwq3RNXwOWxjM1OM6/FuvEB31gu +ZDvRSto+65sLcImXVlJXfB7Ou3RvdB9dRkHY1L9TWNEmDVqialjOBOtffOao3eME5JJ yibtg37ltj/1/i1JI2nIxA2F0tPaoNKjg9LWEjkOoAQmvszq4Lp//KKCoihPT2ianG3G 23A0dOX/6rx/k3v9YSZ1MqV7NSctxyAeI/iVyjplnALVAGcgkSRK2XLmm91n9qJlONW4 hshsmN4m1xzCQXSznVaGxFJfOh9LC81q02juMht8G/5FFBYxOt4MFVg3KiEAnhvhslIk 4pfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743508157; x=1744112957; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=YQFZrAjPSyZJeoC6y3bR1+73GGpzYaR1wZxYfHb0PWc=; b=rEOmt6mmcsc/hK0iKGb7yvWhLgtr5EEISI2yp0gDVDq7hgZ7Je44WTLVOsAcoUy8g2 QoPkm+z6/i5kdBd1HSTbbR8pw/FW8wEmWbWOxOOFV5jthCG4zTt+bOCtKzYr4fm3iIOj GniZJZhL1nHSYNLifcDEUGg4FNXJj0298/nyyHbD7fdsjNluCigzyFzh2q5fDF6MzaYQ JLyO6SojadNJLIIgRlc62psyH6z4tW4ABSfOXVAG7kenKqXfFEGuLP+E2amfuDkDD6uu czGY0QJoZVh+lx/0nKpVd9aZMAEyF50yNhSAaQoo8E4kB5rTsidMf3JZF04kzKfnQHaa WzrA== X-Forwarded-Encrypted: i=1; AJvYcCVmXMMDgYSGgHCnyz4ierxhnkj5yKeCtiOavKYVByGyifs/peXHrQBrS/9RmwVg1VVm3bytPke5ng4=@lists.php.net X-Gm-Message-State: AOJu0YywHa2X9rxJRlAhbzIDNz6CMcE6nMMfOa9ht1+k/Lv+hlRE2txM 8Hg1ugiFc8TnhiQqW6kJG1kcrvzWcZ9XNRsxCmRKFeyfTt2mngpaJvkdNy+cHUleLoNn3h7uoZ1 D0aroR92X78N5v9H+Zg7w4gLkYcE= X-Gm-Gg: ASbGnctcL/pKpRtl7+5FwR/jUHyRTg5aLWRB0wVV9g4kD2ML3P9dGZJnN12P8FDeyb+ JCFgHK7OtZIUSDKGFjE358jKnHMEnAc3DiIj+M8K/56SmMF1W+YcsRgl1TqzGcYRCh5YzCEv251 Coc3CP8Y5D/6al+pWVWrkfCpD/dz0SOilrZUPgD9KRbZ31pSx77AqqS85z X-Google-Smtp-Source: AGHT+IG90Mozpmqs3gvkD5KDu8OPBoe+lHf8a79m9DzxRjysLufMxcjyh5VEPygWG660UX2Qmc9hJd7TWFfit7EkDRA= X-Received: by 2002:a17:907:7202:b0:abf:6ec7:65e9 with SMTP id a640c23a62f3a-ac738bdb21bmr1058350666b.43.1743508156540; Tue, 01 Apr 2025 04:49:16 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 References: <059201dba2ee$35c7bc00$a1573400$@glaive.pro> In-Reply-To: Date: Tue, 1 Apr 2025 13:48:49 +0200 X-Gm-Features: AQ5f1Jr2inPyhOmMjYV6aDOl2CIsqvRN3o36oME4nt_kZTYHcJ2AiYlP-Lynz3w Message-ID: Subject: Re: [PHP-DEV] Usable classes? To: Eugene Sidelnyk Cc: =?UTF-8?Q?Tim_D=C3=BCsterhus?= , Juris Evertovskis , php internals Content-Type: multipart/alternative; boundary="00000000000055766a0631b62005" From: kjarli@gmail.com (Lynn) --00000000000055766a0631b62005 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Apr 1, 2025 at 1:24=E2=80=AFPM Eugene Sidelnyk wrote: > The wording =E2=80=9Cspicy=E2=80=9D, =E2=80=9Cheretical=E2=80=9D, =E2=80= =9Cliterally unusable=E2=80=9D, =E2=80=9Cvibe=E2=80=9D, the use >> of ChatGPT, and the current calendar date requires me to ask: >> > > Actually, if we put aside all of this, and think about it more seriously, > personally I myself find it somewhat tedious to have every class have > interface for the sake of being able to decorate it. > > Everything we expose as api for the client code normally should have an > interface, and usually it ends up with superficial name: either suffixed > with Interface (I know it is in PHP), or prefixed with I (C#), or just a > normal name, while the actual class is suffixed with Impl (Java), or any > other naming that only shows the problem of superficial separation. > > In my opinion, it could be a good thing to consider if we could do it mor= e > easily. > > It reminds me of C++, where every class has .h file with headers without > actual implementation (IOW, interface, client code uses it), and the actu= al > implementation in .cpp file. Though the two are still physically separate= d, > they still logically make the same unit. > > Having the ability to implement the class, we'd not need to suffix > interfaces with Interface all around where there's only one implementatio= n > of it. On the other hand, it still makes sense to keep normal full fledge= d > interfaces, since these are usable when there are multiple different > implementations (say, we have BankTransactionsGateway as the interface, a= nd > PrivatBankTransactionsGateway, MonoBankTransactionsGateway as > implementations), since in this case interface is a normal expected > abstraction, that should be kept separate. > > Thank you > Reading the original post I actually thought about being able to implement the interface of a final class that doesn't have an interface by default. This would include all public and protected methods and properties. Would make it really easy to decorate/mock/stub objects. Not sure if this would be considered a good practice, but certainly would help with composition where otherwise nothing is possible. Would also make it possible for a single object to implement the interface of multiple different objects and fulfill all the contracts, which probably opens up a whole new can of worms, but I could see myself using it to support legacy code. --00000000000055766a0631b62005 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Apr 1, = 2025 at 1:24=E2=80=AFPM Eugene Sidelnyk <zsidelnik@gmail.com> wrote:
The wording =E2=80=9Csp= icy=E2=80=9D, =E2=80=9Cheretical=E2=80=9D, =E2=80=9Cliterally unusable=E2= =80=9D, =E2=80=9Cvibe=E2=80=9D, the use
of ChatGPT, and the current calendar date requires me to ask:

Actually, if w= e put aside all of this, and think about it more seriously, personally I my= self find it somewhat tedious to have every class have interface for the sa= ke of being able to decorate it.
=C2=A0
Everything we expose as api for the client code normally should = have an interface, and usually it ends up with superficial name: either suf= fixed with Interface (I know it is in PHP), or prefixed with I (C#), or jus= t a normal name, while the actual class is suffixed with Impl (Java), or an= y other naming that only shows the problem of superficial separation.
=

In my opinion, it could be a = good thing to consider if we could do it more easily.

It reminds me of C++, where every class has .= h file with headers without actual implementation (IOW, interface, client c= ode uses it), and the actual implementation in .cpp file. Though the two ar= e still physically separated, they still logically make the same unit.

Having the ability to implem= ent the class, we'd not need to suffix interfaces with Interface all ar= ound where there's only one implementation of it. On the other hand, it= still makes sense to keep normal full fledged interfaces, since these are = usable when there are multiple different implementations (say, we have Bank= TransactionsGateway as the interface, and PrivatBankTransactionsGateway, Mo= noBankTransactionsGateway as implementations), since in this case interface= is a normal expected abstraction, that should be kept separate.

Thank you=C2=A0

Reading the original post I actually thought abou= t being able to implement the interface of a final class that doesn't h= ave an interface by default. This would include all public and protected me= thods and properties. Would make it really easy to decorate/mock/stub objec= ts.

Not sure if this would be considered a good pr= actice, but certainly would help with composition where otherwise nothing i= s possible. Would also make it possible for a single object to implement th= e interface of multiple different objects and fulfill all the contracts, wh= ich probably opens up a whole new can of worms,=C2=A0but I could see myself= using it to support legacy code.
--00000000000055766a0631b62005--