Re: [PHP-DEV][DISCUSSION] grapheme_* functions adds locale in parameter (or any?)

Hi, Internals I created an RFC and Draft PR. - https://wiki.php.net/rfc/grapheme_add_locale_for_case_insensitive - https://github.com/php/php-src/pull/18792 I would like to discussion. Feel free to comment. Regards Yuya -- --- Yuya Hamada (tekimen) - https://tekitoh-mem

Re: [PHP-DEV][DISCUSSION] grapheme_* functions adds locale in parameter (or any?)

> Note that this RFC was about making the functions independent from the global > mode as set by `setlocale()`. > > There is no issue in adding an explicit $locale parameter to those functions > if the default value doesn’t depend on a global state. > > —Claude > Hi, Claude Thanks for the commen

Re: [PHP-DEV][DISCUSSION] grapheme_* functions adds locale in parameter (or any?)

> > However, I watched that RFC: https://wiki.php.net/rfc/strtolower-ascii > and https://github.com/php/php-src/pull/7511, > Perhaps, I should not locale-dependant for grapheme functions. Note that this RFC was about making the functions independent from the global mode as set by `setlocale()`.

Re: [PHP-DEV][DISCUSSION] grapheme_* functions adds locale in parameter (or any?)

2025年6月5日(木) 18:02 Claude Pache : > > > > > Le 5 juin 2025 à 03:04, youkidearitai a écrit : > > > > Hi, Internals > > > > I would like adds locale parameter that already there are grapheme_* > > functions. > > Because Unicode is locale-dependency but grapheme_* functions is not > > locale-depende

Re: [PHP-DEV][DISCUSSION] grapheme_* functions adds locale in parameter (or any?)

> Le 5 juin 2025 à 03:04, youkidearitai a écrit : > > Hi, Internals > > I would like adds locale parameter that already there are grapheme_* > functions. > Because Unicode is locale-dependency but grapheme_* functions is not > locale-dependency. > > For example, Add $locale parameter is bel

[PHP-DEV][DISCUSSION] grapheme_* functions adds locale in parameter (or any?)

Hi, Internals I would like adds locale parameter that already there are grapheme_* functions. Because Unicode is locale-dependency but grapheme_* functions is not locale-dependency. For example, Add $locale parameter is below. ``` grapheme_extract( string $haystack, int $size, int $ty

Re: [PHP-DEV] [DISCUSSION] Ternary nullcoalesce operator

On Thu, 20 Feb 2025, 13:15 Mihail Liahimov, <91lia...@gmail.com> wrote: > Now we have nullcoalesca operator in PHP: > > $a = $a ?? $b; > > And nullcoalesce assignment operator: > > $a ??= $b; > > (which is equivalent of previous example with nullcoalesce operator). > > Also we have a short syntax

[PHP-DEV] [DISCUSSION] Ternary nullcoalesce operator

Now we have nullcoalesca operator in PHP: $a = $a ?? $b; And nullcoalesce assignment operator: $a ??= $b; (which is equivalent of previous example with nullcoalesce operator). Also we have a short syntax for ternary operator: $a = $a ?: $b; which is equivalent to: $a = $a ? $b : $a; Maybe

Re: [PHP-DEV] Discussion: Remove file statcache?

On Sun, Dec 22, 2024 at 4:55 PM Calvin Buckley wrote: > On Dec 22, 2024, at 10:57 AM, Kévin Dunglas wrote: > > > > On Sun, Dec 22, 2024 at 10:44 AM Jakub Zelenka wrote: > > Thinking about it, there might be a possibility to address it (at least > on Linux) using fanotify. Not sure about other p

Re: [PHP-DEV] Discussion: Remove file statcache?

On 22 December 2024 20:32:47 GMT, Niels Dossche wrote: >All in all though, I'm not convinced by the parameter approach. >I'd like a proper solution rather than some plaster. >There are some options: >1) Try to fix the stat cache. >2) Put stat cache behind an ini knob. >3) Get rid of the stat ca

Re: [PHP-DEV] Discussion: Remove file statcache?

On 22/12/2024 13:16, Rowan Tommins [IMSoP] wrote: > On 21/12/2024 20:50, Niels Dossche wrote: >> Adding a parameter for a cache, which should've been transparent in the >> first place, to every file operation is messy. > > > I would say it's less messy than having to work out when to turn a glob

Re: [PHP-DEV] Discussion: Remove file statcache?

On Dec 22, 2024, at 10:57 AM, Kévin Dunglas wrote: > > On Sun, Dec 22, 2024 at 10:44 AM Jakub Zelenka wrote: > Thinking about it, there might be a possibility to address it (at least on > Linux) using fanotify. Not sure about other platforms but maybe there are > some solutions to address it.

Re: [PHP-DEV] Discussion: Remove file statcache?

On Sun, Dec 22, 2024 at 10:44 AM Jakub Zelenka wrote: > Thinking about it, there might be a possibility to address it (at least on > Linux) using fanotify. Not sure about other platforms but maybe there are > some solutions to address it. Also it might get a bit complex and not sure > how much th

Re: [PHP-DEV] Discussion: Remove file statcache?

On 21/12/2024 20:50, Niels Dossche wrote: Adding a parameter for a cache, which should've been transparent in the first place, to every file operation is messy. I would say it's less messy than having to work out when to turn a global setting on or off. In particular, it would be horrible fo

Re: [PHP-DEV] Discussion: Remove file statcache?

> I suppose a possible alternative would be to modify all file system >> mutation functions (file_put_contents(), touch(), etc.) to flush the cache, >> which for whatever reason doesn't happen now. That would be above my skill >> level, though, so someone else would need to do it. Also, I don't k

Re: [PHP-DEV] Discussion: Remove file statcache?

On Sun, Dec 22, 2024 at 5:12 AM Larry Garfield wrote: > On Sat, Dec 21, 2024, at 10:43 AM, Jakub Zelenka wrote: > > On Fri, Dec 20, 2024 at 8:29 PM Larry Garfield > wrote: > >> Background: PHP has a not-often-considered feature, the stat-cache. > That is, the runtime caches the OS stat() call fo

Re: [PHP-DEV] Discussion: Remove file statcache?

On Sat, Dec 21, 2024, at 10:43 AM, Jakub Zelenka wrote: > On Fri, Dec 20, 2024 at 8:29 PM Larry Garfield wrote: >> Background: PHP has a not-often-considered feature, the stat-cache. That >> is, the runtime caches the OS stat() call for files, so that subsequent >> reads on the same file can be

Re: [PHP-DEV] Discussion: Remove file statcache?

On Sat, Dec 21, 2024, at 2:18 PM, Juris Evertovskis wrote: > While it is nice the Symfony and WordPress wouldn't suffer a lot from > dropping this cache, what's the impact on scripts that are processing > hundreds of files? > > Would doing ` $stat = stat($filename);` instead of separate calls to >

Re: [PHP-DEV] Discussion: Remove file statcache?

On 21/12/2024 21:38, Rowan Tommins [IMSoP] wrote: > > > On 21 December 2024 18:49:46 GMT, Niels Dossche > wrote: >>> $perms = fileperms($name, statcache: true); >>> $size = filesize($name, statcache: true); >> >> In my opinion, this will become very messy. > > Could you elaborate? Adding a pa

Re: [PHP-DEV] Discussion: Remove file statcache?

On 21 December 2024 18:49:46 GMT, Niels Dossche wrote: >> $perms = fileperms($name, statcache: true); >> $size = filesize($name, statcache: true); > >In my opinion, this will become very messy. Could you elaborate? >Changing a default would be another BC break. "Another" after what? Adding

RE: [PHP-DEV] Discussion: Remove file statcache?

While it is nice the Symfony and WordPress wouldn't suffer a lot from dropping this cache, what's the impact on scripts that are processing hundreds of files? Would doing ` $stat = stat($filename);` instead of separate calls to `filemtime` and `filesize` actually be important? Or would it still am

Re: [PHP-DEV] Discussion: Remove file statcache?

On 21/12/2024 19:43, Rowan Tommins [IMSoP] wrote: > Rather than a global setting, which would make behaviour even more > unpredictable in libraries and out-the-box applications, I wonder if we could > make the cache explicit on the functions that use it? > > I'm thinking for instance of an extra

Re: [PHP-DEV] Discussion: Remove file statcache?

On 21 December 2024 16:43:39 GMT, Jakub Zelenka wrote: >I would prefer to disable it by default but keep some option (INI) to >re-enable it. Rather than a global setting, which would make behaviour even more unpredictable in libraries and out-the-box applications, I wonder if we could make t

Re: [PHP-DEV] Discussion: Remove file statcache?

On Fri, Dec 20, 2024 at 8:29 PM Larry Garfield wrote: > Background: PHP has a not-often-considered feature, the stat-cache. That > is, the runtime caches the OS stat() call for files, so that subsequent > reads on the same file can be faster. However, it's even less realized > that it's a singl

Re: [PHP-DEV] Discussion: Remove file statcache?

On 20 December 2024 19:26:41 GMT, Larry Garfield wrote: >There's been some discussion about making the cache disable-able, though the >consensus now seems to be leaning toward getting rid of it outright: > >https://github.com/php/php-src/pull/17178 Just to fill in more context, which wasn't o

Re: [PHP-DEV] Discussion: Remove file statcache?

On 21.12.2024 at 06:49, Larry Garfield wrote: > On Fri, Dec 20, 2024, at 3:35 PM, Christoph M. Becker wrote: > >> I still think the stat cache should be *deprecated* first. That gives >> users a chance to reconsider calling multiple stat related functions >> instead of doing a single stat() call.

Re: [PHP-DEV] Discussion: Remove file statcache?

On Fri, Dec 20, 2024, at 3:35 PM, Christoph M. Becker wrote: > On 20.12.2024 at 20:26, Larry Garfield wrote: > >> Background: PHP has a not-often-considered feature, the stat-cache. That >> is, the runtime caches the OS stat() call for files, so that subsequent >> reads on the same file can be f

Re: [PHP-DEV] Discussion: Remove file statcache?

Am 20.12.2024 um 20:26 schrieb Larry Garfield: Would you support such a removal? +1 from me. Here is an example of how the stat-cache can lead to interesting situations in testing: https://github.com/sebastianbergmann/phpunit/issues/5996#issuecomment-2422018481

Re: [PHP-DEV] Discussion: Remove file statcache?

On Fri, Dec 20, 2024 at 8:29 PM Larry Garfield wrote: > Background: PHP has a not-often-considered feature, the stat-cache. That > is, the runtime caches the OS stat() call for files, so that subsequent > reads on the same file can be faster. However, it's even less realized > that it's a singl

Re: [PHP-DEV] Discussion: Remove file statcache?

Hi, On Fri, Dec 20, 2024 at 10:37 PM Christoph M. Becker wrote: > On 20.12.2024 at 20:26, Larry Garfield wrote: > > > Background: PHP has a not-often-considered feature, the stat-cache. > That is, the runtime caches the OS stat() call for files, so that > subsequent reads on the same file can be

Re: [PHP-DEV] Discussion: Remove file statcache?

On 20.12.2024 at 20:26, Larry Garfield wrote: > Background: PHP has a not-often-considered feature, the stat-cache. That is, > the runtime caches the OS stat() call for files, so that subsequent reads on > the same file can be faster. However, it's even less realized that it's a > single-file

Re: [PHP-DEV] Discussion: Remove file statcache?

On Dec 20, 2024, at 3:26 PM, Larry Garfield wrote: > > Background: PHP has a not-often-considered feature, the stat-cache. That is, > the runtime caches the OS stat() call for files, so that subsequent reads on > the same file can be faster. However, it's even less realized that it's a > sin

[PHP-DEV] Discussion: Remove file statcache?

Background: PHP has a not-often-considered feature, the stat-cache. That is, the runtime caches the OS stat() call for files, so that subsequent reads on the same file can be faster. However, it's even less realized that it's a single-file cache. It literally only applies when you try to do t

Re: [PHP-DEV] [Discussion] Make objects unpackable by default

On Thursday, 21 November 2024 at 10:05, Christian Schneider wrote: > Am 14.11.2024 um 22:27 schrieb Gina P. Banyard intern...@gpb.moe: > > > Agreed, this bites us constantly when needing to reason about what an > > "object" is in PHP. > > Similar to array it mixes the concept of a struct, with

Re: [PHP-DEV] [Discussion] Make objects unpackable by default

Am 14.11.2024 um 22:27 schrieb Gina P. Banyard : > Agreed, this bites us constantly when needing to reason about what an > "object" is in PHP. > Similar to array it mixes the concept of a struct, with that of a reference > value, and "overloading" various behaviours (e.g. iterators and ArrayAcces

Re: [PHP-DEV] [Discussion] Make objects unpackable by default

I absolutely agree that unpacking objects to functions is a bad idea, my use case for this is different. Take for example that you have API endpoint that returns user balance ```php readonly class Balance { public function __construct( public float $debt, public float $credit,

Re: [PHP-DEV] [Discussion] Make objects unpackable by default

I do know about get_object_vars, but for me foreach ($object as $prop) {} looks nicer and a little bit faster (probably because there are no function calls). Also it's more flexible because in future you can implement an Iterator on class and alter iteration behavior. But after reading through http

Re: [PHP-DEV] [Discussion] Make objects unpackable by default

On Thursday, 14 November 2024 at 17:24, Larry Garfield wrote: > On Thu, Nov 14, 2024, at 7:37 AM, Christian Schneider wrote: > > > Am 14.11.2024 um 10:59 schrieb Marco Pivetta ocram...@gmail.com: > > > > > On Thu, 14 Nov 2024, 11:29 MrMeshok, ilyaorlov...@gmail.com wrote: > > > > > > > Hello,

Re: [PHP-DEV] [Discussion] Make objects unpackable by default

On Thu, Nov 14, 2024, at 7:37 AM, Christian Schneider wrote: > Am 14.11.2024 um 10:59 schrieb Marco Pivetta : >> On Thu, 14 Nov 2024, 11:29 MrMeshok, wrote: >>> Hello, Internals! >>> >>> As you know if you try to unpack a regular object (`...$object`) you will >>> get an error: Only arrays and T

Re: [PHP-DEV] [Discussion] Make objects unpackable by default

Am 14.11.2024 um 10:59 schrieb Marco Pivetta : > On Thu, 14 Nov 2024, 11:29 MrMeshok, wrote: >> Hello, Internals! >> >> As you know if you try to unpack a regular object (`...$object`) you will >> get an error: Only arrays and Traversables can be unpacked. >> I don't really see a reason for this

Re: [PHP-DEV] [Discussion] Make objects unpackable by default

On Thu, 14 Nov 2024, 11:29 MrMeshok, wrote: > Hello, Internals! > > As you know if you try to unpack a regular object (`...$object`) you will > get an error: Only arrays and Traversables can be unpacked. > I don't really see a reason for this restriction, because foreach on > objects works perfec

[PHP-DEV] [Discussion] Make objects unpackable by default

Hello, Internals! As you know if you try to unpack a regular object (`...$object`) you will get an error: Only arrays and Traversables can be unpacked. I don't really see a reason for this restriction, because foreach on objects works perfectly fine, so I made a feature request on GitHub to change

Re: [PHP-DEV][DISCUSSION] Multibyte for levenshtein function

2024年10月6日(日) 14:45 youkidearitai : > > 2024年10月5日(土) 1:20 Tim Düsterhus : > > > > Hi > > > > Am 2024-09-25 09:21, schrieb youkidearitai: > > > I tried implement mb_levenshtein function and create an RFC. > > > https://wiki.php.net/rfc/mb_levenshtein > > > https://github.com/php/php-src/pull/16043

[PHP-DEV][DISCUSSION][RFC] Grapheme cluster for levenshtein function

Hi, internals. I creating grapheme_levenshtein function that measure levenshtein distance based on grapheme cluster in Unicode. https://github.com/php/php-src/pull/16428 RFC is here: https://wiki.php.net/rfc/grapheme_levenshtein I want to discussion about grapheme_levenshtein function. Feel free

Re: [PHP-DEV] [Discussion] PHP Ecosystem Promotion

On Fri, Oct 11, 2024, at 12:48 PM, Oladoyinbo Vincent wrote: > Hello everyone, earlier this morning, I visited the official Python website > and discovered a section highlighting what Python is used for. This section > provides a brief overview of the most popular frameworks and libraries built

[PHP-DEV] [Discussion] PHP Ecosystem Promotion

Hello everyone, earlier this morning, I visited the official Python website and discovered a section highlighting what Python is used for. This section provides a brief overview of the most popular frameworks and libraries built with Python. In my opinion, this is a great idea, as it increases vis

Re: [PHP-DEV][DISCUSSION] Multibyte for levenshtein function

2024年10月5日(土) 1:20 Tim Düsterhus : > > Hi > > Am 2024-09-25 09:21, schrieb youkidearitai: > > I tried implement mb_levenshtein function and create an RFC. > > https://wiki.php.net/rfc/mb_levenshtein > > https://github.com/php/php-src/pull/16043 > > > > I would like discussion, feel free to comment.

Re: [PHP-DEV][DISCUSSION] Multibyte for levenshtein function

Hi Am 2024-09-25 09:21, schrieb youkidearitai: I tried implement mb_levenshtein function and create an RFC. https://wiki.php.net/rfc/mb_levenshtein https://github.com/php/php-src/pull/16043 I would like discussion, feel free to comment. Thank you for your RFC. I share the concern raised by cm

[PHP-DEV][DISCUSSION] Multibyte for levenshtein function

Hello Internals. I tried implement mb_levenshtein function and create an RFC. https://wiki.php.net/rfc/mb_levenshtein https://github.com/php/php-src/pull/16043 I would like discussion, feel free to comment. Thank you. Yuya. -- --- Yuya Hamada (tekimen) - https://tekitoh

Re: [PHP-DEV] [Discussion] Implementing interfaces via traits

Hi Folks Thanks for the replies. If interface default methods are not entirely off the table, then I agree that's a far better option, for sure! I'll hold off on writing my arguments for them until a thread pops up, I think it makes a lot of sense though. So consider the idea of traits + interfac

Re: [PHP-DEV] [Discussion] Implementing interfaces via traits

On Tuesday, 27 August 2024 at 09:25, Brent Roose wrote: > Back to PHP, using traits as types seems impossible, since traits are a > compile-time copy/paste mechanism, which means there’s no type information > available about them at runtime. > > However, allowing traits to implement interfaces

Re: [PHP-DEV] [Discussion] Implementing interfaces via traits

> On Aug 30, 2024, at 10:15 AM, Larry Garfield wrote: > I would be very much in favor of revisiting Interface Default Methods, > though, as I think it would be a strong feature, and it's one found in nearly > all of our sibling languages at this point. PHP is weird for not having > them. I be

Re: [PHP-DEV] [Discussion] Implementing interfaces via traits

On Fri, Aug 30, 2024, at 1:09 AM, Michał Marcin Brzuchalski wrote: > Hi Brent, > > wt., 27 sie 2024 o 09:28 Brent Roose napisał(a): >> Good morning internals >> >> >> I’d like to test the waters about an RFC idea: allowing traits to implement >> interfaces, and consequently a class that uses su

Re: [PHP-DEV] [Discussion] Implementing interfaces via traits

Hi Brent, wt., 27 sie 2024 o 09:28 Brent Roose napisał(a): > Good morning internals > > I’d like to test the waters about an RFC idea: allowing traits to > implement interfaces, and consequently a class that uses such a trait will > automatically implement the interface as well. > > The original

Re: [PHP-DEV] [Discussion] Implementing interfaces via traits

On Tue, 27 August in 2024 at 10:31, Brent Roose wrote: > Good morning internals > > I’d like to test the waters about an RFC idea: allowing traits to > implement interfaces, and consequently a class that uses such a trait will > automatically implement the interface as well. > > The original idea

[PHP-DEV] [Discussion] Implementing interfaces via traits

Good morning internals I’d like to test the waters about an RFC idea: allowing traits to implement interfaces, and consequently a class that uses such a trait will automatically implement the interface as well. The original idea comes from Rust, where traits can be used as types. I read a very in

Re: [PHP-DEV][Discussion] Should All String Functions Become Multi-Byte Safe?

2024年8月17日(土) 9:17 Mike Schinkel : > > > On Aug 16, 2024, at 8:02 PM, Rowan Tommins [IMSoP] > > wrote: > > On 17 August 2024 00:25:13 BST, Mike Schinkel wrote: > >> I am not sure I agree with you that adding Unicode support is the wrong > >> angle, per se. > >> > >> A strong argument could be m

Re: [PHP-DEV][Discussion] Should All String Functions Become Multi-Byte Safe?

> On Aug 16, 2024, at 8:02 PM, Rowan Tommins [IMSoP] > wrote: > On 17 August 2024 00:25:13 BST, Mike Schinkel wrote: >> I am not sure I agree with you that adding Unicode support is the wrong >> angle, per se. >> >> A strong argument could be made that Unicode support is a necessary but not

Re: [PHP-DEV][Discussion] Should All String Functions Become Multi-Byte Safe?

On 17 August 2024 00:25:13 BST, Mike Schinkel wrote: >I am not sure I agree with you that adding Unicode support is the wrong angle, >per se. > >A strong argument could be made that Unicode support is a necessary but not >sufficient building block for "internationalization support." IOW, if

Re: [PHP-DEV][Discussion] Should All String Functions Become Multi-Byte Safe?

On 16 August 2024 23:11:18 BST, Nick Lockheart wrote: >I used the rather broad title "Should All String Functions Become >Multi-Byte Safe" because there are many smaller related topics, but my >intention was to discuss multi-byte in general I think it was probably not the best choice, because

Re: [PHP-DEV][Discussion] Should All String Functions Become Multi-Byte Safe?

Hi Nick, > On Aug 16, 2024, at 6:11 PM, Nick Lockheart wrote: > > I wanted to reply generally to this and not to any person in > particular, as I'm the one who started the thread. > > I used the rather broad title "Should All String Functions Become > Multi-Byte Safe" because there are many sma

Re: [PHP-DEV][Discussion] Should All String Functions Become Multi-Byte Safe?

> On Aug 16, 2024, at 3:36 PM, Rowan Tommins [IMSoP] > wrote: > On 16 August 2024 19:44:22 BST, Mike Schinkel wrote: >> Let me see if I understand your argument correctly? You are asserting that >> Unicode is "too complex" to be handled in the standard library so that >> complexity should ins

Re: [PHP-DEV] [DISCUSSION] Class Constant Enums?

On Fri, Aug 16, 2024, at 1:31 PM, Arvids Godjuks wrote: > Hello Larry, > I feel obliged to remind about the 80/20 rule where the last 20% of > progress ends up being 80% of all the work. And from the discussion > it's already looking like there are some major questions and caveats > and engine

Re: [PHP-DEV][Discussion] Should All String Functions Become Multi-Byte Safe?

I wanted to reply generally to this and not to any person in particular, as I'm the one who started the thread. I used the rather broad title "Should All String Functions Become Multi-Byte Safe" because there are many smaller related topics, but my intention was to discuss multi-byte in general, a

Re: [PHP-DEV][Discussion] Should All String Functions Become Multi-Byte Safe?

On 16 August 2024 19:44:22 BST, Mike Schinkel wrote: >Let me see if I understand your argument correctly? You are asserting that >Unicode is "too complex" to be handled in the standard library so that >complexity should instead be shouldered individually by each and every PHP >developer who

Re: [PHP-DEV][Discussion] Should All String Functions Become Multi-Byte Safe?

> On Aug 12, 2024, at 4:25 PM, Rowan Tommins [IMSoP] > wrote: > > On 12/08/2024 17:37, Mike Schinkel wrote: >> A really standout paragraph from that link is: >> >> "IMO, the whole situation is a shame. Unicode should be >> in the stdlib of every language by default. It’s the lingua >> franca of

Re: [PHP-DEV] [DISCUSSION] Class Constant Enums?

On Fri, 16 Aug 2024 at 17:18, Larry Garfield wrote: > On Fri, Aug 16, 2024, at 6:35 AM, Alexandru Pătrănescu wrote: > > Hi Nick, > >> > >> Is there any interest in having enums as class constants? > >> > >> I'm often finding cases where I would like to have an enum inside of a > >> class, but don

Re: [PHP-DEV] [DISCUSSION] Class Constant Enums?

On Fri, 16 Aug 2024 at 04:37, Nick Lockheart wrote: > Hi, > > Is there any interest in having enums as class constants? > > I'm often finding cases where I would like to have an enum inside of a > class, but don't want a free-floating enum that's basically like > another class. > > When dealing w

Re: [PHP-DEV] [DISCUSSION] Class Constant Enums?

On Aug 16, 2024, at 10:17, Larry Garfield wrote: > > I would have to research to see if other languages did this, but one option > would be to allow an inner class to extend an outer class even if it's final, > which would essentially give us sealed classes for free: > > final class Outer > {

Re: [PHP-DEV] [DISCUSSION] Class Constant Enums?

On Fri, Aug 16, 2024, at 16:17, Larry Garfield wrote: > On Fri, Aug 16, 2024, at 6:35 AM, Alexandru Pătrănescu wrote: > > Hi Nick, > >> > >> Is there any interest in having enums as class constants? > >> > >> I'm often finding cases where I would like to have an enum inside of a > >> class, but d

Re: [PHP-DEV] [DISCUSSION] Class Constant Enums?

On Fri, Aug 16, 2024, at 6:35 AM, Alexandru Pătrănescu wrote: > Hi Nick, >> >> Is there any interest in having enums as class constants? >> >> I'm often finding cases where I would like to have an enum inside of a >> class, but don't want a free-floating enum that's basically like >> another clas

Re: [PHP-DEV] [DISCUSSION] Class Constant Enums?

Hi Nick, > > Is there any interest in having enums as class constants? > > I'm often finding cases where I would like to have an enum inside of a > class, but don't want a free-floating enum that's basically like > another class. > > .. > > class SSHClient { > >public const enum CommandR

Re: [PHP-DEV] [DISCUSSION] Class Constant Enums?

> On Aug 15, 2024, at 9:37 PM, Nick Lockheart wrote: > > Hi, > > Is there any interest in having enums as class constants? > I'm often finding cases where I would like to have an enum inside of a > class, but don't want a free-floating enum that's basically like > another class. > > When dealin

[PHP-DEV] [DISCUSSION] Class Constant Enums?

Hi, Is there any interest in having enums as class constants? I'm often finding cases where I would like to have an enum inside of a class, but don't want a free-floating enum that's basically like another class. When dealing with state, it's nice to have a human readable const to represent that

Re: [PHP-DEV] [DISCUSSION] C++ Enhancements in Zend API

On Thu, Aug 15, 2024 at 4:39 PM Derick Rethans wrote: > On 15 August 2024 18:42:58 BST, Lanre wrote: > >On Thu, Aug 15, 2024 at 11:33 AM Derick Rethans wrote: > > > >> On 15 August 2024 18:10:11 BST, Lanre wrote: > >> > >> >You're embarrassing yourself John, read my very first paragraph (you >

Re: [PHP-DEV] [DISCUSSION] C++ Enhancements in Zend API

On 15 August 2024 18:42:58 BST, Lanre wrote: >On Thu, Aug 15, 2024 at 11:33 AM Derick Rethans wrote: > >> On 15 August 2024 18:10:11 BST, Lanre wrote: >> >> >You're embarrassing yourself John, read my very first paragraph (you got >> this). >> >> We have said this before, but you *really* need t

Re: [PHP-DEV] [DISCUSSION] C++ Enhancements in Zend API

John reached out to me directly, but i think he raised some valid points that I should address here, so here it is: On Thu, Aug 15, 2024 at 1:56 PM John Coggeshall wrote: > Lanre, > > I think you're expectations are probably unrealistic if you expected to > drop a PR in a week to add C++ suppor

Re: [PHP-DEV] [DISCUSSION] C++ Enhancements in Zend API

On Thu, Aug 15, 2024 at 11:53 AM Bilge wrote: > > > On Thu, 15 Aug 2024, 18:50 Lanre, wrote: > >> >> Why am I the only person being reminded of the rules? >> > > Maybe because during the aggregate time you've spent slandering your > fellow man, you could have written that RFC you claim to not h

Re: [PHP-DEV] [DISCUSSION] C++ Enhancements in Zend API

On Thu, 15 Aug 2024, 18:50 Lanre, wrote: > > Why am I the only person being reminded of the rules? > Maybe because during the aggregate time you've spent slandering your fellow man, you could have written that RFC you claim to not have had the time to write.

Re: [PHP-DEV] [DISCUSSION] C++ Enhancements in Zend API

On Thu, Aug 15, 2024 at 11:42 AM Lanre wrote: > > > On Thu, Aug 15, 2024 at 11:33 AM Derick Rethans wrote: > >> On 15 August 2024 18:10:11 BST, Lanre wrote: >> >> >You're embarrassing yourself John, read my very first paragraph (you got >> this). >> >> We have said this before, but you *really*

Re: [PHP-DEV] [DISCUSSION] C++ Enhancements in Zend API

On Thu, Aug 15, 2024 at 11:33 AM Derick Rethans wrote: > On 15 August 2024 18:10:11 BST, Lanre wrote: > > >You're embarrassing yourself John, read my very first paragraph (you got > this). > > We have said this before, but you *really* need to stop using > condescending language, and ad-hominems

Re: [PHP-DEV] [DISCUSSION] C++ Enhancements in Zend API

On 15 August 2024 18:10:11 BST, Lanre wrote: >You're embarrassing yourself John, read my very first paragraph (you got >this). We have said this before, but you *really* need to stop using condescending language, and ad-hominems like this. cheers Derick

Re: [PHP-DEV] [DISCUSSION] C++ Enhancements in Zend API

On Thu, Aug 15, 2024 at 8:51 AM John Coggeshall wrote: > > > On Aug 14 2024, at 5:27 pm, Lanre wrote: > > > Can you point out where either of us suggested writing PHP in another > language? You might be mixing this up with the C11 thread, which has > nothing to do with this. All I'm proposing i

Re: [PHP-DEV] [DISCUSSION] C++ Enhancements in Zend API

On Aug 14 2024, at 5:27 pm, Lanre wrote: > > Can you point out where either of us suggested writing PHP in another > language? You might be mixing this up with the C11 thread, which has nothing > to do with this. All I'm proposing is improving the current C++ support in > the engine. > https

Re: [PHP-DEV] [DISCUSSION] C++ Enhancements in Zend API

On Thu, Aug 15, 2024, 6:35 AM Lanre wrote: > Arvids wrote "I don't think C sees a lot of development any more, so it >> makes sense to move towards C++." > > > >> > Nah, I meant the specific conversation with Pierre Joye, it wasn't going > anywhere. I stand by all my points so why would I just le

Re: [PHP-DEV] [DISCUSSION] C++ Enhancements in Zend API

> > Arvids wrote "I don't think C sees a lot of development any more, so it > makes sense to move towards C++." Yeah he wrote that right after "PHP has C as core and has allowed C++ for extensions. Expanding that support is a no-brainer, especially since modern C++ has stepped up in major ways".

Re: [PHP-DEV] [DISCUSSION] C++ Enhancements in Zend API

> On Aug 14, 2024, at 5:27 PM, Lanre wrote: > >> On Wed, Aug 14, 2024 at 2:32 PM Mike Schinkel wrote: >> > On Aug 14, 2024, at 3:05 PM, Arvids Godjuks >> > wrote: >> > PHP has C as core and has allowed C++ for extensions. Expanding that >> > support is a no-brainer, especially since modern C+

Re: [PHP-DEV] [DISCUSSION] C++ Enhancements in Zend API

On Wed, Aug 14, 2024 at 2:32 PM Mike Schinkel wrote: > > On Aug 14, 2024, at 3:05 PM, Arvids Godjuks > wrote: > > > > I want to remind everyone on the thread that code does not only have to > be written, which is the "easy part", but it also has to be supported by > everyone into the future and

Re: [PHP-DEV] [DISCUSSION] C++ Enhancements in Zend API

> On Aug 14, 2024, at 3:05 PM, Arvids Godjuks wrote: > > I want to remind everyone on the thread that code does not only have to be > written, which is the "easy part", but it also has to be supported by > everyone into the future and chances that the original author sticks around > are not th

Re: [PHP-DEV] [DISCUSSION] C++ Enhancements in Zend API

I want to remind everyone on the thread that code does not only have to be written, which is the "easy part", but it also has to be supported by everyone into the future and chances that the original author sticks around are not that high to do it. The Rust thing is shitposting for the sake of shi

Re: [PHP-DEV] [DISCUSSION] C++ Enhancements in Zend API

On Wed, Aug 14, 2024 at 4:30 AM Pascal Chevrel wrote: > Le 14/08/2024 à 05:03, Lanre a écrit : > > > > Mozilla introduced Rust years ago, yet Firefox remains primarily C++, > > with only about 3% of the codebase in Rust. > > Hi, > > 10.3% now https://openhub.net/p/firefox/analyses/latest/language

Re: [PHP-DEV] [DISCUSSION] C++ Enhancements in Zend API

On 11 August 2024 23:52:00 BST, Lanre wrote: >I’m considering adding some C++ enhancements to the Zend API. These changes >would be encapsulated within `#ifdef __cplusplus` guards, so they wouldn’t >interfere with the existing C implementation. The primary goal is to >provide a nicer interface

Re: [PHP-DEV] [DISCUSSION] C++ Enhancements in Zend API

On Wed, Aug 14, 2024 at 3:54 AM Pierre Joye wrote: > > > On Wed, Aug 14, 2024, 11:07 AM Lanre wrote: > >> >> On Tue, Aug 13, 2024 at 4:28 PM Mike Schinkel >> wrote: >> >>> >>> On Aug 12, 2024 at 4:13 PM, > wrote: >>> You’d have to be seriously naive to believe that “the entire industry is >>> a

Re: [PHP-DEV] [DISCUSSION] C++ Enhancements in Zend API

On Wed, Aug 14, 2024, 11:07 AM Lanre wrote: > > On Tue, Aug 13, 2024 at 4:28 PM Mike Schinkel wrote: > >> >> On Aug 12, 2024 at 4:13 PM, > wrote: >> You’d have to be seriously naive to believe that “the entire industry is >> actively trying to move AWAY from C/C++.” >> >> >> Well, there is this:

Re: [PHP-DEV] [DISCUSSION] C++ Enhancements in Zend API

On 2024-08-14 16:03, Lanre wrote: On Tue, Aug 13, 2024 at 4:28 PM Mike Schinkel Well, there is this: https://media.defense.gov/2023/Dec/06/2003352724/-1/-1/0/THE-CASE-FOR-MEMORY-SAFE-ROADMAPS-TLP-CLEAR.PDF

Re: [PHP-DEV] [DISCUSSION] C++ Enhancements in Zend API

On Tue, Aug 13, 2024 at 4:28 PM Mike Schinkel wrote: > > On Aug 12, 2024 at 4:13 PM, > wrote: > You’d have to be seriously naive to believe that “the entire industry is > actively trying to move AWAY from C/C++.” > > > Well, there is this: > > > https://media.defense.gov/2023/Dec/06/2003352724/-1

Re: [PHP-DEV] [DISCUSSION] C++ Enhancements in Zend API

> > On Aug 12, 2024 at 4:13 PM, mailto:lnearw...@gmail.com)> wrote: > > > You’d have to be seriously naive to believe that “the entire industry is > actively trying to move AWAY from C/C++.” > > Well, there is this: https://media.defense

Re: [PHP-DEV] [DISCUSSION] C++ Enhancements in Zend API

On Tue, Aug 13, 2024, 3:16 AM Lanre wrote: I'm sure the idea of enhancing C++ makes no sense to you, and would be a > waste of your time and energy, but not everyone is that stupid/incompetent > so even if i do get bored of maintaining it, literally any C++ dev can pick > it up, it really is that

Re: [PHP-DEV] [DISCUSSION] C++ Enhancements in Zend API

Friend, honest to god you are really not doing yourself any favors here. You came on this list with a proposal. I think it's a bad idea, and I've enumerated the reasons why I have come to that conclusion: If it's so easy and transparent to improve support for C++, it could easily exist outside o

Re: [PHP-DEV][Discussion] Should All String Functions Become Multi-Byte Safe?

On 12/08/2024 17:37, Mike Schinkel wrote: A really standout paragraph from that link is: "IMO, the whole situation is a shame. Unicode should be in the stdlib of every language by default. It’s the lingua franca of the internet! It’s not even new: we’ve been living with Unicode for 20 years now.

  1   2   3   4   5   6   >