Hi Juliette,
On Mon, 15 Nov 2021 at 23:36, wrote:
>
> I've been asked to post the link to the Twitter discussion in this
> thread for visibility.
>
> The Twitter thread generated, and is still generating, quite a lot of
> discussion,
I'm not going to quote from the Twitter thread partly as lot
On Tue, Nov 16, 2021 at 5:55 PM Larry Garfield
wrote:
> 1. If we adopt the RFC right now as-is, the market has ~12 months to add
> the attribute. If we instead have a default-true flag that changes to
> default false in the future, it means at minimum 24 months in which to add
> the attribute
> Le 17 nov. 2021 à 00:56, Larry Garfield a écrit :
>
> They'll get a deprecation, but... we're shouting from the rooftops that
> deprecations shouldn't be a big red warning, so if you want a big red warning
> you can't get that until PHP 9.
Deprecation notices *are* big red warnings. They
On Tue, Nov 16, 2021, at 4:10 PM, Sara Golemon wrote:
> On Mon, Nov 15, 2021 at 11:21 AM Larry Garfield
> wrote:
>
>> A possible idea to help make this transition (which I do support) more
>> gradual:
>>
>> Instead of an "allow" attribute, introduce a boolean flag attribute.
>>
>>
On Mon, Nov 15, 2021 at 11:21 AM Larry Garfield
wrote:
> A possible idea to help make this transition (which I do support) more
> gradual:
>
> Instead of an "allow" attribute, introduce a boolean flag attribute.
>
> #[DynamicProperties(true)]
> class Beep {}
>
> The attribute marks whether
On Tue, Nov 16, 2021 at 6:00 PM Andreas Heigl wrote:
> Hey list.
> Which performance improvement of the "original state" of the RFC? As
> that was one of the questions that were not 100% answered: What are the
> benefits for the language. And while those 8 bit that Nikita mentioned
> in the
Hey list.
On 16.11.21 16:26, Deleu wrote:
On Tue, Nov 16, 2021 at 3:59 PM James Gilliland wrote:
On Tue, Nov 16, 2021 at 4:23 AM Rowan Tommins
wrote:
On 16/11/2021 09:27, Andreas Heigl wrote:
I see, yes, code that is 100% perfectly tested can get away without
the language performing
On Tue, Nov 16, 2021 at 3:59 PM James Gilliland wrote:
> On Tue, Nov 16, 2021 at 4:23 AM Rowan Tommins
> wrote:
>
> > On 16/11/2021 09:27, Andreas Heigl wrote:
> > >
> > >> I see, yes, code that is 100% perfectly tested can get away without
> > >> the language performing any error checking at
On Tue, Nov 16, 2021 at 4:23 AM Rowan Tommins
wrote:
> On 16/11/2021 09:27, Andreas Heigl wrote:
> >
> >> I see, yes, code that is 100% perfectly tested can get away without
> >> the language performing any error checking at all - the behaviour is
> >> all guaranteed by the tests. I would be
On 16/11/2021 09:27, Andreas Heigl wrote:
I see, yes, code that is 100% perfectly tested can get away without
the language performing any error checking at all - the behaviour is
all guaranteed by the tests. I would be very surprised if even 1% of
PHP applications can claim such
Hi list,
On Tue, 16 Nov 2021, 00:21 Deleu, wrote:
> I see a pattern in these discussions from two mindsets: one thinking about
> how we should design the future and another thinking about how we preserve
> the past.
I would frame that differently as those who
1. Predominantly write new code
Hey all
On 16.11.21 10:16, Rowan Tommins wrote:
On 15/11/2021 17:20, Andreas Heigl wrote:
When you are testing whether writing 'X' to a property and then
reading from that property gives that 'X' back, then everything should
be good.
I see, yes, code that is 100% perfectly tested can get
On 15/11/2021 17:20, Andreas Heigl wrote:
When you are testing whether writing 'X' to a property and then
reading from that property gives that 'X' back, then everything should
be good.
I see, yes, code that is 100% perfectly tested can get away without the
language performing any error
On 15/11/2021 23:35, php-internals_nos...@adviesenzo.nl wrote:
Either way, in my estimation, handling this deprecation will - again -
require not insignificant dev-time from maintainers to determine the
best course of action for each flagged instance and to implement the
changes, and what with
On Tue, Nov 16, 2021, 00:36 wrote:
> L.S.,
>
> As some of you may have seen, I posted a thread on Twitter a few days
> back referencing this RFC:
> https://twitter.com/jrf_nl/status/1459221549429542920
>
> I've been asked to post the link to the Twitter discussion in this
> thread for
L.S.,
As some of you may have seen, I posted a thread on Twitter a few days
back referencing this RFC:
https://twitter.com/jrf_nl/status/1459221549429542920
I've been asked to post the link to the Twitter discussion in this
thread for visibility.
The Twitter thread generated, and is still
On Mon, Nov 15, 2021 at 3:11 PM Deleu wrote:
> By design my REST API utilizes dynamic properties. I've always found it to
>> be a feature of PHP, not a bug.
>>
>> --
>> Chase Peeler
>> chasepee...@gmail.com
>>
>
> I am in the unfortunate position of inheriting a system with such REST API
>
Den 2021-11-15 kl. 10:52, skrev Derick Rethans:
Dear Internals,
On Wed, 10 Nov 2021, Nikita Popov wrote:
On Wed, Aug 25, 2021 at 12:02 PM Nikita Popov wrote:
This RFC takes the more direct route of deprecating this
functionality entirely. I expect that this will have relatively
little
>
> By design my REST API utilizes dynamic properties. I've always found it to
> be a feature of PHP, not a bug.
>
> --
> Chase Peeler
> chasepee...@gmail.com
>
I am in the unfortunate position of inheriting a system with such REST API
design. I can never build new REST APIs to replace the old
On Mon, Nov 15, 2021 at 3:02 PM James Gilliland wrote:
> On Mon, Nov 15, 2021 at 3:53 AM Derick Rethans wrote:
>
> > Dear Internals,
> >
> > On Wed, 10 Nov 2021, Nikita Popov wrote:
> >
> > > On Wed, Aug 25, 2021 at 12:02 PM Nikita Popov
> > wrote:
> > >
> > > > This RFC takes the more direct
On Mon, Nov 15, 2021 at 3:53 AM Derick Rethans wrote:
> Dear Internals,
>
> On Wed, 10 Nov 2021, Nikita Popov wrote:
>
> > On Wed, Aug 25, 2021 at 12:02 PM Nikita Popov
> wrote:
> >
> > > This RFC takes the more direct route of deprecating this
> > > functionality entirely. I expect that this
On Mon, Nov 15, 2021, at 10:52 AM, Rowan Tommins wrote:
> On 15/11/2021 16:23, Andreas Heigl wrote:
>> One thing, that can verify the correct working of properties, whether
>> that is dynamic or static ones, is testing.
>
>
> Can it? I can't actually see how that would work, without also having a
Hey Rowan, hey all
On 15.11.21 17:52, Rowan Tommins wrote:
On 15/11/2021 16:23, Andreas Heigl wrote:
One thing, that can verify the correct working of properties, whether
that is dynamic or static ones, is testing.
Can it? I can't actually see how that would work, without also having a
way
On 15/11/2021 16:23, Andreas Heigl wrote:
One thing, that can verify the correct working of properties, whether
that is dynamic or static ones, is testing.
Can it? I can't actually see how that would work, without also having a
way to detect when dynamic properties were accessed, which
Hey Nikita.
On 15.11.21 14:50, Nikita Popov wrote:
[...]
I hope that the new "Motivation" section clarifies things a bit, especially
in regards to why "static analysis" is only a partial solution to this
problem: https://wiki.php.net/rfc/deprecate_dynamic_properties#motivation
Thanks for the
On Mon, Nov 15, 2021 at 2:52 PM Andreas Heigl wrote:
>
> And as far as I can see from the PR associated with this RFC it will not
> make life easier for the internals team. It is not like there will be
> hundreds of lines code less to maintain. On the contrary. There is more
> code and more
On Mon, Nov 15, 2021 at 1:52 PM Andreas Heigl wrote:
> Hea all.
>
> On 15.11.21 10:52, Derick Rethans wrote:
> > Dear Internals,
> >
> > On Wed, 10 Nov 2021, Nikita Popov wrote:
> >
> >> On Wed, Aug 25, 2021 at 12:02 PM Nikita Popov
> wrote:
> >>
> >>> This RFC takes the more direct route of
On Mon, Nov 15, 2021 at 1:52 PM Andreas Heigl wrote:
> Hea all.
>
> On 15.11.21 10:52, Derick Rethans wrote:
> > Dear Internals,
> >
> > On Wed, 10 Nov 2021, Nikita Popov wrote:
> >
> >> On Wed, Aug 25, 2021 at 12:02 PM Nikita Popov
> wrote:
> >>
> >>> This RFC takes the more direct route of
On 15.11.21 14:19, Rowan Tommins wrote:
On 15/11/2021 12:51, Andreas Heigl wrote:
PS: Am I the only one missing whether this is a 2/3 or a 50%+1 vote in
the RFC?
All votes require a 2/3 majority as of
https://wiki.php.net/rfc/abolish-narrow-margins
Thanks!
I just stumbled over the fact
On 15/11/2021 12:51, Andreas Heigl wrote:
PS: Am I the only one missing whether this is a 2/3 or a 50%+1 vote in
the RFC?
All votes require a 2/3 majority as of
https://wiki.php.net/rfc/abolish-narrow-margins
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing
Hea all.
On 15.11.21 10:52, Derick Rethans wrote:
Dear Internals,
On Wed, 10 Nov 2021, Nikita Popov wrote:
On Wed, Aug 25, 2021 at 12:02 PM Nikita Popov wrote:
This RFC takes the more direct route of deprecating this
functionality entirely. I expect that this will have relatively
little
Dear Internals,
On Wed, 10 Nov 2021, Nikita Popov wrote:
> On Wed, Aug 25, 2021 at 12:02 PM Nikita Popov wrote:
>
> > This RFC takes the more direct route of deprecating this
> > functionality entirely. I expect that this will have relatively
> > little impact on modern code (e.g. in Symfony
On Wed, Aug 25, 2021 at 12:02 PM Nikita Popov wrote:
> Hi internals,
>
> I'd like to propose the deprecation of "dynamic properties", that is
> properties that have not been declared in the class (stdClass and
> __get/__set excluded, of course):
>
>
Le 13/10/2021 à 14:42, Rowan Tommins a écrit :
On 13/10/2021 10:17, Guilliam Xavier wrote:
Off-topic:
if ( class_exists('\\WeakMap') ) {
People should stop using a leading slash in FQCN *strings*.
\Foo::class is "Foo", not "\Foo". It might work generally but that's
asking for problems
On 13/10/2021 10:17, Guilliam Xavier wrote:
Off-topic:
if ( class_exists('\\WeakMap') ) {
People should stop using a leading slash in FQCN *strings*.
\Foo::class is "Foo", not "\Foo". It might work generally but that's
asking for problems (e.g. for autoloaders).
(Sorry.)
Hah,
Le 13/10/2021 à 11:17, Guilliam Xavier a écrit :
Off-topic:
if ( class_exists('\\WeakMap') ) {
People should stop using a leading slash in FQCN *strings*. \Foo::class is
"Foo", not "\Foo". It might work generally but that's asking for problems
(e.g. for autoloaders).
(Sorry.)
And why not ?
On Wed, Oct 13, 2021 at 11:17 AM Guilliam Xavier
wrote:
> Off-topic:
>
> if ( class_exists('\\WeakMap') ) {
>>
>
> People should stop using a leading slash in FQCN *strings*. \Foo::class
> is "Foo", not "\Foo". It might work generally but that's asking for
> problems (e.g. for autoloaders).
>
Off-topic:
if ( class_exists('\\WeakMap') ) {
>
People should stop using a leading slash in FQCN *strings*. \Foo::class is
"Foo", not "\Foo". It might work generally but that's asking for problems
(e.g. for autoloaders).
(Sorry.)
On 13/10/2021 02:43, Tim Starling wrote:
I think it would still be the biggest compatibility break since PHP
4->5.
I think this is a rather large exaggeration. It's certainly a use case
we need to consider, but it's not on the scale of call-time
pass-by-reference, or removing the mysql
On Wed, Oct 13, 2021 at 3:43 AM Tim Starling
wrote:
> On 12/10/21 9:23 pm, Nikita Popov wrote:
> > Based on the received feedback, I've updated the RFC to instead provide
> an
> > #[AllowDynamicProperties] attribute as a way to opt-in to the use of
> > dynamic properties. As previously
On 12/10/21 9:23 pm, Nikita Popov wrote:
> Based on the received feedback, I've updated the RFC to instead provide an
> #[AllowDynamicProperties] attribute as a way to opt-in to the use of
> dynamic properties. As previously discussed, this won't allow us to
> completely remove dynamic properties
On Tue, Oct 12, 2021 at 3:52 PM Levi Morrison
wrote:
> > Based on the received feedback, I've updated the RFC to instead provide
> an
> > #[AllowDynamicProperties] attribute as a way to opt-in to the use of
> > dynamic properties. As previously discussed, this won't allow us to
> > completely
> Based on the received feedback, I've updated the RFC to instead provide an
> #[AllowDynamicProperties] attribute as a way to opt-in to the use of
> dynamic properties. As previously discussed, this won't allow us to
> completely remove dynamic properties from the language model anymore, but
> it
On Wed, Aug 25, 2021 at 12:02 PM Nikita Popov wrote:
> Hi internals,
>
> I'd like to propose the deprecation of "dynamic properties", that is
> properties that have not been declared in the class (stdClass and
> __get/__set excluded, of course):
>
>
Den 2021-08-25 kl. 12:02, skrev Nikita Popov:
Hi internals,
I'd like to propose the deprecation of "dynamic properties", that is
properties that have not been declared in the class (stdClass and
__get/__set excluded, of course):
https://wiki.php.net/rfc/deprecate_dynamic_properties
This has
45 matches
Mail list logo
