Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics

> On 8 Jul 2020, at 13:16, Michał Marcin Brzuchalski > wrote: > > Hi Stephen, > > śr., 8 lip 2020 o 07:09 Stephen Reay napisał(a): > >> ... >> IMO (and I know it’s not universal) acronyms should remain upper case. >> Camel case is about upper casing the first letter of each word. The lette

Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics

Hi Stephen, śr., 8 lip 2020 o 07:09 Stephen Reay napisał(a): > ... > IMO (and I know it’s not universal) acronyms should remain upper case. > Camel case is about upper casing the first letter of each word. The letters > of an acronym are all the first letters of words, thus DOM not Dom, etc. >

Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics

> On 8 Jul 2020, at 05:11, Larry Garfield wrote: > > On Tue, Jul 7, 2020, at 4:22 PM, Miguel Rosales wrote: >> Larry Garfield wrote on 07/07/2020 16:46: >>> This has reached the 2 week mark, but there's not been much discussion. >>> Anyone else want to weigh in? >>> >> >> I guess I'm missi

[PHP-DEV] Re: Including "Disable the ability to use concrete types in PHAR metadata" in PHP 8.0?

On Mon, Jul 6, 2020 at 8:58 PM tyson andre wrote: > Hi internals, > > https://bugs.php.net/bug.php?id=76774 has been open since 2018-08-21. > > That ticket proposes the following: > > > I propose that we disable the ability to have concrete types included in > the serialized metadata by > > provi

[PHP-DEV] [RFC] Don't automatically unserialize Phar metadata outside getMetadata()

Hi internals, I've created https://wiki.php.net/rfc/phar_stop_autoloading_metadata as mentioned earlier in https://externals.io/message/110856 This aims to add the mitigations described in https://externals.io/message/105271#105291 , which seemed to be the most straightforward approach to avoi

Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics

There are some problem by using double back slash for PHP namespace? Eg. Instead of \PHP\String be just \\String. Em ter, 7 de jul de 2020 19:04, Larry Garfield escreveu: > On Tue, Jul 7, 2020, at 4:22 PM, Miguel Rosales wrote: > > Larry Garfield wrote on 07/07/2020 16:46: > > > This has reache

Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics

On Tue, Jul 7, 2020, at 4:22 PM, Miguel Rosales wrote: > Larry Garfield wrote on 07/07/2020 16:46: > > This has reached the 2 week mark, but there's not been much discussion. > > Anyone else want to weigh in? > > > > I guess I'm missing something obvious here, but the RFC says: > > > 5. Compon

[PHP-DEV] [RFC][DISCUSSION] debug_backtrace alternative as an array of StackFrame objects

Hi internals, following recently added alternative to `token_get_all()` in form of a dedicated class `PhpToken` I've made a similar proposal for collecting stack traces by introducing `StackFrame::getTrace()` and `StackFrame` which replaces array with keys and values known from `debug_backtrace()`

Re: [PHP-DEV] Proposal: A way for classes to define a response to any primitive type cast

On 07/07/2020 18:13, Josh Bruce wrote: Decided to put something together:https://github.com/joshbruce/external-project-proposals/blob/master/php-concepts/interact-with-instance-as-php.md Hi Josh, Reading through this, it seems to cover a few different concepts, which are certainly related,

Re: [PHP-DEV] Proposal: A way for classes to define a response to any primitive type cast

> On Jul 6, 2020, at 11:54 AM, Marco Pivetta wrote: > > Hey Josh, > > Similar proposals were raised recently for `__toArray()`: see > https://externals.io/message/108369#108369 > > I'd endorse avoiding object-to- casts via cast operations: they are > a good source of bugs. > My rationale for

Re: [PHP-DEV] Trait constants

> On 28 Jun 2020, at 19:33, Nikita Popov wrote: > > On Sat, Jun 27, 2020 at 3:53 PM Stephen Reay > > wrote: > >> Hi, >> >> It’s always struck me as slightly odd that traits don’t support constants >> the way classes and interfaces do. >> I tried to find an exp

Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics

On Tue, 7 Jul 2020 at 15:47, Larry Garfield wrote: > This has reached the 2 week mark, but there's not been much discussion. > Anyone else want to weigh in? > Looks good; nothing more to say. 👍 Peter

Re: [PHP-DEV] [RFC] Property write visibility

On Tue, Jul 7, 2020, at 2:35 AM, André Rømcke wrote: > > > > ergonomic, and in the case of magic method usage improve performance. > >> > > > > I think this is a good direction to explore, but would recommend delaying > > it until PHP 8.1. As the RFC and discussion note, the design space here > > o

Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics

On 07/07/2020 15:46, Larry Garfield wrote: This has reached the 2 week mark, but there's not been much discussion. Anyone else want to weigh in? We wanted to add that, general sentiment seems to be moving towards using Exceptions for communicating errors, potentially including a large effor

Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics

On Tue, Jun 23, 2020, at 7:30 PM, Larry Garfield wrote: > Greetings, Internalians. > > There has been much talk of the \PHP namespace of late, including one > unsuccessful RFC. In the discussion, the pushback broke down into two > main camps: > > * We should never namespace anything ever. > *

[PHP-DEV] 8.0 Feature Freeze in 4 weeks

Per the timetable at https://wiki.php.net/todo/php80 , the PHP-8.0 branch will be cut in FOUR WEEKS on Aug 4th just prior to the release of php-8.0.0beta1 on Aug 6th. Please note that August 4th marks FEATURE FREEZE for 8.0. All RFCs currently in discussion targeting 8.0 should plan to begin votin

Re: [PHP-DEV] [RFC] Property write visibility

> > ergonomic, and in the case of magic method usage improve performance. >> > > I think this is a good direction to explore, but would recommend delaying > it until PHP 8.1. As the RFC and discussion note, the design space here > overlaps significantly with both readonly/immutability and property

Re: [PHP-DEV] [RFC] Property write visibility

> > I think the only thing worth mentioning where references are concerned is > that "$x =& $this->prop" is considered a write of $this->prop, not a read, > so it is subject to the write visibility. But once the reference is > acquired, visibility no longer factors into the behavior. > > Ok, thank