Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:126187 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 75E961A00BD for ; Sun, 29 Dec 2024 06:49:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1735454797; bh=+gXHvne6tpiOphDC2SWmsjY4Wxk5K0ROpsEQYyCCsPk=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=BvIG4gQsVfzb7WBnTA0RfdfsXUrP7xaiLfGq714Dxjd8V091HbTIXQEinc/DPNFQv bzFfZFJFw1lsxCZzED8jG7KEOBj8Spj+hcjs2PzVkRrk/I8rPtaxRGuwxpyVNyaIb6 esA+6PW4t4aafAsC2kA+CqttTd3oICGMIwlM8ORonEFEmbjiXq+D+sZ5TWxSVzALRq GXA/PwzSC4IONyuCPMZsda3gdJJujwAerNfEDn9j6SZNX9bwMJIBboKgIhPoc+qHOY 7oOpo5nb8dmv87xPOv7OV6hP+l/5L0Ow1KSKNftRCWTbsUcLMUd/Kbo+JrvJO7ys6G 9t5bBsGyIUQfg== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 9B017180039 for ; Sun, 29 Dec 2024 06:46:36 +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_H2,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from mail-yb1-f178.google.com (mail-yb1-f178.google.com [209.85.219.178]) (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 ; Sun, 29 Dec 2024 06:46:32 +0000 (UTC) Received: by mail-yb1-f178.google.com with SMTP id 3f1490d57ef6-e46ebe19368so8990571276.0 for ; Sat, 28 Dec 2024 22:49:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1735454971; x=1736059771; 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=+gXHvne6tpiOphDC2SWmsjY4Wxk5K0ROpsEQYyCCsPk=; b=UCzBxd8+/D2KLbRvltyTvCRPkWqOOZmRge2dc1Q9kiD8Vf5d0yyq0JEP4KETRFZhOI y0bvB0yQjOPxej5d2ItQJTKPuWeLFrxF34QWanYNQcUO8ld2MMAJ9mhs89Nm11Jez3CC ldQ2p9Ds98I2b/dBU+1d9g3JGlqcUIWe8rfYVIAolZz7FlJMameEps/VjqX4T9NAdyIU 88siXLQim/IVeIwO13XrRQt/WjlCyzhkvMx2nmiGRorLrLRvnHeS7NzBJIud9772d4FN 7QvEO2CC4i/sozD4xAhFT8xVE8lE7L4t0GGMabDIT/+CdC3227Z28B9i2EZkISt8eVVE wqIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735454971; x=1736059771; 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=+gXHvne6tpiOphDC2SWmsjY4Wxk5K0ROpsEQYyCCsPk=; b=cgMd51shS8DPccZZ4Xa6KJ1RWiqybeAijO1fNnOhYDRyD/Z/cxJc4yc+3SNl/dAySQ KaaAKq9PiYsi78wO6kfVBYATg2b14oBtrYMHjFFLbJvJI0qGqa2oxMmuwnZ6dsvp/2SK QnXtD6Gqa/9qesQ/kJYhW1o1ra4dnDlELDSaWF+uuAN1uhkqFc+nSGQxhh7snzFkagYX eiw6CqQvjsLttmMIS6Uk72Gdi2cYqtlQt6wzRFt/E9vWIAhln35wIdQH3/rdaJQBDcK2 RYKgensVixaMEiHjKIRQzjiJ5FMvne6lC9Q0AdeMJ7kYK6/EO1OvPnOrRGIdm93RL6OQ sfkw== X-Gm-Message-State: AOJu0YwAm8oXhsCkHn3ZMTy7KAE/uAYdHE/LffJLR8apufO3+GEI7Iuq mHcPdmE0MszZdKdpr4TV/fLMCL1GWHpuswDcTD+Fvuac5EdqSvz5p/QjfPWne8lW3GYQ+5n2Qpi gI7pWIx5uikKVuPV3qTuOEMPq1nsS90MPf40= X-Gm-Gg: ASbGnctEmZFvay30F8ASxA94gtXiT/8+36d1HOsyKio+cvP2eMHe0Rx2hCt+v/EHwaR SFFaxCnjmoxF1iJLMOHzNHMGx2189T6dy0kGjqA== X-Google-Smtp-Source: AGHT+IFuEdek5/OhbvKnjGx8jwi9heuFyHB9VsR9rP0r+RZZrYdiEnj3FUv7HOpk5xL9E9APcFKFzwojnU5JRkKCGZQ= X-Received: by 2002:a05:690c:6911:b0:6ef:96f9:2f48 with SMTP id 00721157ae682-6f3f823eb81mr241418817b3.37.1735454971370; Sat, 28 Dec 2024 22:49:31 -0800 (PST) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 References: <087a01db596a$e7525660$b5f70320$@glaive.pro> In-Reply-To: <087a01db596a$e7525660$b5f70320$@glaive.pro> Date: Sun, 29 Dec 2024 08:49:19 +0200 Message-ID: Subject: Re: [PHP-DEV] [RFC] [Discussion] Optional interfaces To: Juris Evertovskis Cc: php internals Content-Type: multipart/alternative; boundary="00000000000017a839062a63199d" From: drealecs@gmail.com (=?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?=) --00000000000017a839062a63199d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Dec 28, 2024, 22:58 Juris Evertovskis wrote: > Hi, > > > > I would like to propose a new syntax that let=E2=80=99s you implement an = interface > only if it exists. > > > > `class MyClass extends ?OptionalInterface {}` > > > > If the `OptionalInterface` exists, the class implements it. If no such > interface can be found, it is ignored. > > > > https://wiki.php.net/rfc/optional-interfaces > > > Hi Juris, I think the proposal looks good but I some some points to be discussed: From what I understand, the autoloading mechanism would be triggered for the optional interface, but it would not be an error if it would not succeed. I think we should explicitly spell this out in the RFC, to make it clear that autoloading will be attempted. If an interface was not available at class declaration time, the function class_implements (on both class and object) will return false going forward, as if the class definition did not contain the interface at all? Similarly, if at runtime the object would be passed to a function/method that has the parameter type of that interface, would it fail saying that the object is not an instance of that interface? Note: autoloading is not triggered when just using an interface/class name in a parameter type or as return type. I think completely erasing the interface sounds good, I just think it should be explicitly spelled out in the RFC, and all the implications that follows. If a second class will implement the same optional interface, will it trigger autoloading again? I think it should. If in the meantime, between defining two such classes, the interface would be defined (using a hack or some sort), would it cause problems? I think that given the current existing workarounds this is a valid concern. To avoid problems, it would be wise to completely erase the interface from first class definition when it was not available, even if the second class might have it. -- Alex --00000000000017a839062a63199d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Dec 28, 2024, 22:58 Juris Evertovskis= <juris@glaive.pro> wrote:
=

Hi,

= =C2=A0

I would like to propose a ne= w syntax that let=E2=80=99s you implement an interface only if it exists.

=C2=A0

`class MyClass extends ?OptionalInterface {}`

<= p class=3D"MsoNormal">=C2=A0

If the= `OptionalInterface` exists, the class implements it. If no such interface = can be found, it is ignored.

=C2=A0

http= s://wiki.php.net/rfc/optional-interfaces


Hi Juris,

I think the proposal looks good but I= some some points to be discussed:

<= p class=3D"MsoNormal">

From w= hat I understand, the autoloading mechanism would be triggered for the opti= onal interface, but it would not be an error if it would not succeed. I thi= nk we should explicitly spell this out in the RFC, to make it clear that au= toloading will be attempted.

If an interface was not available at class declaration time, the funct= ion class_implements (on both class and object) will return false going for= ward, as if the class definition did not contain the interface at all?

Similarly, if at runtime the= object would be passed to a function/method that has the parameter type of= that interface, would it fail saying that the object is not an instance of= that interface?
Note: autoloading is not triggered = when just using an interface/class name in a parameter type or as return ty= pe.

I think completely e= rasing the interface sounds good, I just think it should be explicitly spel= led out in the RFC, and all the implications that follows.


If a second = class will implement the same optional interface, will it trigger autoloadi= ng again? I think it should.

If in the meantime, between defining two such classes, the interface w= ould be defined (using a hack or some sort), would it cause problems? I thi= nk that given the current existing workarounds this is a valid concern.
To avoid problems, it would be wise to completely erase= the interface from first class definition when it was not available, even = if the second class might have it.

-- Alex

--00000000000017a839062a63199d--