Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:119771 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 54797 invoked from network); 29 Mar 2023 13:55:58 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 29 Mar 2023 13:55:58 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id D7C061804DF for ; Wed, 29 Mar 2023 06:55:56 -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=-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_H2,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE 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-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Wed, 29 Mar 2023 06:55:56 -0700 (PDT) Received: by mail-wm1-f52.google.com with SMTP id n10-20020a05600c4f8a00b003ee93d2c914so11175078wmq.2 for ; Wed, 29 Mar 2023 06:55:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680098155; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=q31M0vz01xpA+BC7Wsvr8EMyDvtG0GOQehOJvJesorQ=; b=iVwW+4810f938z9suknzxnWRSmfIN1nsCudKyjd9QVT8hjmPG54EcWP7hGcd0doWNx L3OLfnXXWLSABza13nqW4peEFNzLNgAp5RBeqJbeSougCwrEDSTSrJmjMk/Wz6J8u5O/ mXwAIgN51xMKVSJNT1QDfw0YanZXCFAdz2+qv7VdWbsSBJxfiAAFkv9itvE6glDGqoIA ZVM8aJ2BKL55IN4as5HmRQVOLAy/i3fMdGgNaUUuZAeI7k0SQXkTq77AQUgK+KyStD3y FgHz/gc6KMduItfDv8fvpbFCf9KZDZxpkw1OTELNGlOwZkFY3bMUPEkuuMcHHLDf/wRv RF7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680098155; h=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=q31M0vz01xpA+BC7Wsvr8EMyDvtG0GOQehOJvJesorQ=; b=n723GwrVhA8Bobn6HCJjacwVzjcMbZ140zbP9RfBkDIIbLPygDCyE/V0hIHPDcPVSx rkE5jgEMzGG8Creeni64ut8lLBKx9wBEnj8ZbTbLIX2oXrat2P9heFvFA3hJ2nPaW+qU h/3nJe8jCVoTrY3tSQRjB6cyYrx08rl9vDMkdSMma/o1wD8/I2V+n8VypYvq0qg/X0hj pyjcH7QZRhxIRlPW8tzn9T+8zW38RdYrj6fjzWwkxTgBachC+4DnQ45o2sDlM50o3S0A 3yHq8czFDamyo9tAn2mDo8Jnz5qk06dvt39kpiazKDNHIus9k+UGuRo6RcKNXB3Mg0jT E7CQ== X-Gm-Message-State: AAQBX9c5l/nCj5pTdgXDen14wtw1pGi0uoQdxnCJhr/mI9jOFA7/2Kmn qqG0i7uJYuJ2WNNcKLWWucSvroCKjlpHTuQRnmmlZHHO3Lc= X-Google-Smtp-Source: AKy350ZTcG0ynm5tMlzhxPR5+0pUF4thDZhu5lnftEnH6zJVM1ogIrVbSs4wVOcdK5M48m1eTn5Oapu/b0rGb1T+fFI= X-Received: by 2002:a05:600c:1c23:b0:3ef:6989:19d4 with SMTP id j35-20020a05600c1c2300b003ef698919d4mr966573wms.0.1680098154932; Wed, 29 Mar 2023 06:55:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Wed, 29 Mar 2023 14:55:43 +0100 Message-ID: To: internals@lists.php.net Content-Type: multipart/alternative; boundary="000000000000b66d9005f80a556c" Subject: Re: [PHP-DEV] [IDEA] allow extending enum From: rowan.collins@gmail.com (Rowan Tommins) --000000000000b66d9005f80a556c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 29 Mar 2023 at 14:22, Rokas =C5=A0leinius wrote= : > Ok so I am trying to find the argumentation here: > > >This is by design. > >The point of enums is to be limiting. > > This is clearly an assumption. That statement is not in the docs or > RFC, nor such an oversimplification makes logical sense to me, but > maybe you have a source to back it up..? > From a theory point of view, *any* type definition is about limiting allowed values. The difference between "mixed" and "integer" is that "mixed" allows both 'Hello' and 42, but "integer" does not - it defines a tighter limit. In the same way, saying "I accept an error code" means "I accept an error code *and nothing else*" - the definition of what is and what isn't an "error code" is deliberately a *limit* on the values that you accept. > > >Re: problem in the OP > >You are approaching the design of this in a fundamentally wrong way. > > The described problem is dealing with error *codes* not *types* An enum is a type, so that's why George was talking about types. He was making the same point, in different words, as I did: the relationship between types implied by the keyword "extends" is not the relationship you want in this case. > The set in question is *finite*, as you say of course, but much larger > and different in principle than in the solution you are proposing. > Problem in OP is looking for a way for end users to keep adding new > domains to the error codes passed to the parent system to be handled. > This is the key point - if you pass an error code that didn't previously exist, the existing system *won't* be able to handle it. That's why enums are inherently restrictive: the system wants to be able to say "this is the list of error codes I understand, don't give me anything else". If you have a system that accepts the new codes as well as the old ones, you can use a union type declaration as George says: enum AdditionalErrorCode { case Code_456; } class ExtendedErrorHandler extends StandardErrorHandler { public function handle(StandardErrorCode|AdditionalErrorCode $code) { switch ( $code ) { case AdditionalErrorCode::Code_456: // handling for new code goes here break; default: // assert($code instanceof StandardErrorCode); parent::handle($code); break; } } } Regards, --=20 Rowan Tommins [IMSoP] --000000000000b66d9005f80a556c--