Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117437
MIME-Version: 1.0
References: <CAKWdMuh=qmE1==KnqqPX-yeNh5oObxFrVcaZ_LNUW+rFzqbN-A@mail.gmail.com>
 <76c399cb-fb29-4583-a212-8eb69740c96b@www.fastmail.com> <CAKWdMuiGK3-090QYB6UhgjUAhhoCjS78B9VbCVFqxMVYqqkO7w@mail.gmail.com>
 <CAC5V6gjYjez68QtD5=H6E0XTuvH-jLY0=Pq3OwowYFH4r-6ofg@mail.gmail.com>
 <CAKWdMuiToZZ9ovS8vAaehuoZbO5R08=f5w1oKkmQr6=p-OBuNA@mail.gmail.com>
 <CAC5V6gg0MHppMTbd5N7oj1PAd7vfCTHqteM+NPBKpjO2LG1zqQ@mail.gmail.com> <CAKWdMuj+GnmhCaUp8DJCFt2QMEta9fsZkT-SiMV333Eo3iJt6Q@mail.gmail.com>
In-Reply-To: <CAKWdMuj+GnmhCaUp8DJCFt2QMEta9fsZkT-SiMV333Eo3iJt6Q@mail.gmail.com>
Date: Mon, 28 Mar 2022 14:53:56 +0200
Message-ID: <CAC5V6giAm5MUuUjJBWToS=ybPL-K+hgV0oiwqAXsu3E-8t3Kjg@mail.gmail.com>
To: Mark Niebergall <mbniebergall@gmail.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000d73e8405db46ce8b"
Subject: Re: [PHP-DEV] Typed constants revisited
From: guilliam.xavier@gmail.com (Guilliam Xavier)

--000000000000d73e8405db46ce8b
Content-Type: text/plain; charset="UTF-8"

> Constants are not abstract in an interface - they must be assigned a
> value. Only classes and methods can be abstract. Within an abstract class
> it is not valid to have an abstract property. Properties can be defined
> `protected int $id;` and optionally assigned a value `protected int $id =
> 5;`, but cannot be `abstract protected int $id;`.
>

That's the *current* state of the language indeed, but to me, [part of]
your proposal looks like introducing "abstract constants"... Maybe I'm
misunderstanding?


> So to me it makes more sense to have constants follow the same syntax as
> properties `public const bool CAN_FLY;` without the `abstract` keyword.
>
> An example:
>
> ```
> abstract class Bird
> {
>     public const bool CAN_FLY;
>     protected bool $isExtinct;
> ```
>
> This allows for similar behavior, similar requirements, and similar syntax
> - consistency ftw!
>

For similarity/consistency, the `$isExtinct` property should probably be
[`public` and] `static` (actually `readonly` too, but cannot be both).

But, again, we can also see some similarity with `static` *methods*, e.g.:

```
abstract class Bird
{
    abstract public const bool CAN_FLY;
    abstract public static function isExtinct(): bool;
}
class Dove extends Bird
{
    // NOTE: the following two lines are required (in the class definition)
    public const bool CAN_FLY = true;
    public function static isExtinct(): bool { return false; }
}
// var_dump(Dove::CAN_FLY);
// var_dump(Dove::isExtinct());
```

Besides, an uninitialized property must be initialized before first read,
but is *not* required to be overridden/redefined (with a value) in a child
class; so in this example (still hypothetical):

```
abstract class Bird
{
    public const bool CAN_FLY;
    public static bool $isExtinct;
}
class Dodo extends Bird
{
    // NOTE: the following two lines are commented out
    // public const bool CAN_FLY = false;
    // public static bool $isExtinct = true;
}
var_dump(Dodo::CAN_FLY);
var_dump(Dodo::$isExtinct);
```

where would the [missing value for constant] error be: on the definition of
class Dodo (like for an unimplemented abstract method), or only when trying
to access Dodo::CAN_FLY (like for an uninitialized property)?


>
> There seems to be interest and good use cases (thanks Sara for the good
> practical example!). At this point I'm going to work on a new RFC with all
> the details and feedback from this discussion.
>
>

Thanks & good luck! =)

-- 
Guilliam Xavier

--000000000000d73e8405db46ce8b--