Re: [PHP-DEV] [RFC] Property hooks, nee accessors

On Mon, May 15, 2023 at 1:41 AM Hendra Gunawan wrote: > 2. The shorthand notations supported (the shortest one) creates > impaired syntax, and not pretty to look at for constructor property > promotion. > It's starting to get crowded in object constructors. The following example is so much more

Re: [PHP-DEV] [RFC] Property hooks, nee accessors

On Tue, May 9, 2023 at 4:38 AM Larry Garfield wrote: > > Ilija Tovilo and I would like to offer another RFC for your consideration. > It's been a while in coming, and we've evolved the design quite a bit just in > the last week so if you saw an earlier draft of it in the past few months, I >

Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures

On Sat, 13 May 2023 at 00:08, Larry Garfield wrote: > That means it's impossible to write code that works from 8.2 to 9.0 > without version checks. The overlap period is only 2 releases (8.3 and > 8.4). That's too short of a window. > Why are we assuming that PHP 9.0 is going to come after

Re: [PHP-DEV] [RFC] Property hooks, nee accessors

> ```php > class User { > private string $first; > private string $last; > public string $fullName { > get => $this->first . ' ' . $this->last; > set => [$this->first, $this->last] = explode(' ', $value, 2); > } > > public function __construct($this->fullName)

Re: [PHP-DEV] [RFC] [Discussion] nameof

(I hope it is ok that I take parts from several mails) Op za 13 mei 2023 om 12:37 schreef Rowan Tommins : > On 13 May 2023 10:04:39 BST, Lydia de Jongh wrote: > > >I prefer a magic constant like `::name` instead of a function call as it > >can be used in a wider scope; for example as a parameter

Re: [PHP-DEV] [RFC] [Discussion] nameof

> I totally agree with Rowan. In many (most?) cases you need the fully > qualified name. > Even or especially for error handling! Of course mostly the error is > somewhere else. But you want to know the starting point. An > unqualified name gets you nowhere. Although backtrace can help you > out.

Re: [PHP-DEV] [RFC] [Discussion] nameof

On 15 May 2023 18:44:47 BST, Robert Landers wrote: >use const \NoExist\TEST; >use \NoExist\Channel; >echo TEST; >echo Channel::class; > >the output is: > >Undefined constant "TEST" in ... >Channel I'm not sure how you got that; according to https://3v4l.org/gltKN only PHP 5.6 has a message with

Re: [PHP-DEV] [RFC] [Discussion] nameof

On 15 May 2023 14:07:31 BST, Lydia de Jongh wrote: >> ... >> #[SomeAttribute(callback: nameof(\Acme\bar(...))] >> ... > >This callback to nameof(). is really terrible  Just to be clear, the "callback:" in that example is existing syntax for named parameters, not part of the nameof()

Re: [PHP-DEV] [VOTE] Use exceptions by default in SQLite3 extension

On Mon, 15 May 2023 at 15:41, someniatko wrote: > The `PDOException` class is actually extending the `RuntimeException`, > not just `Exception`. > Yes, and this is, IMHO, a mistake. Outside SPL, there are only 4 extensions which extend from RuntimeException: - PDO - MySQLi - SNMP - Phar

Re: [PHP-DEV] [VOTE] Use exceptions by default in SQLite3 extension

Got it, thank you for explaining. Regards, Illia / someniatko -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Property hooks, nee accessors

> If there is no forward compatibility consideration, can we simplify > interface definition to this one? > ``` > interface IFace > { > public string $readable; > public string $writeable; > public string $both; > } > ``` After carefully reading the proposal again, I think I know the answer

Re: [PHP-DEV] [VOTE] Use exceptions by default in SQLite3 extension

Hi! It says in the RFC: > PDO is using exceptions, like everyone else. and > Create a new exception class SQLite3Exception, which extends the Exception > class The `PDOException` class is actually extending the `RuntimeException`, not just `Exception`. I am sure it is better to do this for

Re: [PHP-DEV] [VOTE] Use exceptions by default in SQLite3 extension

Hi Illia, thank you for your feedback. This is actually what I did, first, but I changed after feedback from @Girgias: https://github.com/php/php-src/pull/11058#discussion_r1162723112 > You are likely to get push back not just from myself if you propose > it as such in an RFC I don't have a

Re: [PHP-DEV] [RFC] Define proper semantics for range() function

Hello Internals, I plan to put the RFC to a vote tomorrow in its current state, which has not been changed since the 30th of March: https://wiki.php.net/rfc/proper-range-semantics Any final comments or complaints should be raised now. Best regards, George P. Banyard

Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures

On 15 May 2023 09:54:41 BST, "G. P. B." wrote: >Why are we assuming that PHP 9.0 is going to come after PHP 8.4? Historically, PHP has had a major release roughly every five years. The main exception is PHP 6, which was never released - but whose major features became PHP 5.3, five years

Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures

On 15 May 2023 19:38:56 BST, Larry Garfield wrote: >Tangent: If I were to put together an RFC that set out such a 5 year cycle >expectation with reasonable guidelines around when things could be deprecated, >would anyone actually support it? A big yes from me, but I've not had the most

Re: [PHP-DEV] [RFC] [Discussion] nameof

> 3v4l.org is great for verifying things like this, because you can see at a > glance if there's been a change in behaviour in previous versions, or indeed > versions newer than you have installed. If you've got an up to date PhpStorm, > you can actually use it directly from a scratch file.

Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures

> On 15 May 2023, at 19:51, Rowan Tommins wrote: > > On 15 May 2023 19:38:56 BST, Larry Garfield wrote: > >> I agree entirely. Setting reasonable expectations for users to plan around, >> such as a known 5-years-per-major cycle, helps end users far more than >> "whelp, we did something

Re: [PHP-DEV] [RFC] Property hooks, nee accessors

> (Also, when replying, please please remove duplicate names from the to/cc > line. I just got double copies of everything in this thread this morning. > I'm on the list, I don't need to be CCed.) Sorry about that. Not my habit before. > For the second, the problem with omitting the {} is

Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures

On Mon, May 15, 2023, at 6:36 PM, Rowan Tommins wrote: > On 15 May 2023 09:54:41 BST, "G. P. B." wrote: > >>Why are we assuming that PHP 9.0 is going to come after PHP 8.4? > > Historically, PHP has had a major release roughly every five years. The > main exception is PHP 6, which was never

Re: [PHP-DEV] [RFC] Property hooks, nee accessors

Consolidating all replies into a single message. Please try to keep them together so it's easier to respond to. (Also, when replying, please please remove duplicate names from the to/cc line. I just got double copies of everything in this thread this morning. I'm on the list, I don't need

Re: [PHP-DEV] [RFC] Define proper semantics for range() function

Hello! I have one concern about the part: > Emit an E_WARNING when $start or $end is cast to an integer because the other boundary input is a number or numeric string. (e.g. range ('5', 'z'); or range (5, 'z');) Doesn't it limit the

Re: [PHP-DEV] [RFC] Property hooks, nee accessors

Missed one... On Mon, May 15, 2023, at 8:14 AM, Hendra Gunawan wrote: > Can the engine detect these logical errors? > ``` > public string $fullName = "hendra gunawan" => $this->first . " " . > $this->last; > > // or with my proposal: > public string $fullName = "hendra gunawan" get =>

Re: [PHP-DEV] [RFC] Property hooks, nee accessors

On Mon, May 15, 2023, at 8:12 PM, Hendra Gunawan wrote: >> For the second, the problem with omitting the {} is that it creates yet >> another syntax variant. That makes it harder for the parser, for static >> analyzers, for user-space parsing tools like php-parser, etc. That's more >> work

Re: [PHP-DEV] [RFC] [Discussion] nameof

On Mon, May 15, 2023 at 8:18 PM Rowan Tommins wrote: > > On 15 May 2023 18:44:47 BST, Robert Landers wrote: > >use const \NoExist\TEST; > >use \NoExist\Channel; > >echo TEST; > >echo Channel::class; > > > >the output is: > > > >Undefined constant "TEST" in ... > >Channel > > I'm not sure how you

Re: [PHP-DEV] [RFC] Property hooks, nee accessors

On Mon, May 15, 2023, at 8:32 AM, Lynn wrote: > It's starting to get crowded in object constructors. The following example > is so much more readable and maintainable imo. Would it be possible to > still add the quick assignment as a language feature? I'm personally not > happy having property

Re: [PHP-DEV] [RFC] [Discussion] nameof

On 15 May 2023 19:26:09 BST, Robert Landers wrote: >php -a >Interactive shell > >php > use \NoExists\Channel; >php > echo Channel::class; >Channel > >Turns out, it's a CLI specific thing Ah, probably each line in the interactive shell is considered a separate compilation context, like a

Re: [PHP-DEV] [RFC] Property hooks, nee accessors

> Secondary votes are generally discouraged. I can see the argument for > wanting a short-short version of set, given how common the validation use > case is, but => is almost universally the "evaluates to" symbol, so using > that for a set operation rather than get just feels weirdly