On Tue, Apr 11, 2023, 22:14 Gunnard engebreth wrote:
>
> On 4/11/23 3:09 PM, Good Guy wrote:
> > On 08/04/2023 19:36, Stephan Soller wrote:
> >>
> >>
> >> A few days ago I migrated a project from PHP 7.1 to 8.2 and the
> >> amount of
> >> deprecations and fatal errors spooked me a bit
On 4/11/23 3:09 PM, Good Guy wrote:
On 08/04/2023 19:36, Stephan Soller wrote:
A few days ago I migrated a project from PHP 7.1 to 8.2 and the
amount of
deprecations and fatal errors spooked me a bit (details below if you're
interested). That got me wondering about the long-term
On 08/04/2023 19:36, Stephan Soller wrote:
A few days ago I migrated a project from PHP 7.1 to 8.2 and the amount of
deprecations and fatal errors spooked me a bit (details below if you're
interested). That got me wondering about the long-term stability of
PHP (as in
language and API breaks)
Den 2023-04-08 kl. 20:36, skrev Stephan Soller:
Hello,
I'm sorry if this isn't the correct mailing list for that discussion but I
couldn't find a more appropriate one where people actually know how the
wind is
blowing.
A few days ago I migrated a project from PHP 7.1 to 8.2 and the amount of
On Tue, Apr 11, 2023, at 4:32 PM, Jeffrey Dafoe wrote:
> Can you expand a bit more on your use-case?
>
> We have a lot of classes, a small portion of which use dynamic
> properties, but we do not necessarily know which ones do. It’s
> different than, for example, a change to the count
On Tue, Apr 11, 2023, at 6:02 PM, Björn Larsson via internals wrote:
> Den 2023-04-07 kl. 12:58, skrev Jakub Zelenka:
>> Hello,
>>
>> Here is a proposal for an introduction of the PHP Technical Committee:
>>
>> https://wiki.php.net/rfc/php_technical_committee
>>
>> The main purpose of this RFC
Den 2023-04-07 kl. 12:58, skrev Jakub Zelenka:
Hello,
Here is a proposal for an introduction of the PHP Technical Committee:
https://wiki.php.net/rfc/php_technical_committee
The main purpose of this RFC is to have better decision process when
technical conflicts between developer arise.
This
On Monday 10 April 2023 14:17:04 (+02:00), G. P. B. wrote:
> Hello Internals,
>
> Dan and I would like to propose a new core autoloading mechanism [...]
>
> The existing SPL autoloading functions would become aliases to the new
Core
> ones and will continue to work without any migrations
Essentially the same thing here. Removal of dynamic properties will be the next
big one for my team. It's the deprecations that hit huge swaths of code without
really offering much benefit that are annoying.
Yes, we have a _lot_ of classes. Also multiple versions of Zend framework that
we
> Can you expand a bit more on your use-case?
Here are some things I've deliberately used dynamic properties for:
- development proxies (production uses compiled proxies) for remote
objects [can use attribute or magic functions]
- visitor pattern when hacking on parser packages [in PHP 9,
> Ah, I see now what you meant, Robert. This already doesn't hold.
>
> class Foo {
> public int $prop;
> }
> $foo = new Foo();
> $value = '42';
> $foo->prop = $value;
> var_dump($value === $foo->prop);
> // false
I don’t know if this has been closed or discussed further in private but this
On Tue, Apr 11, 2023, 11:32 AM Larry Garfield
wrote:
> But the same people will still complain just as loudly whenever that is,
> because they haven't done anything about it for the past 17 years so
> they're not going to now.
>
Do you know that for a fact or should this statement be classified
On Tue, Apr 11, 2023 at 9:29 AM Jeffrey Dafoe wrote:
> Essentially the same thing here. Removal of dynamic properties will be the
> next big one for my team. It's the deprecations that hit huge swaths of
> code without really offering much benefit that are annoying.
>
> Yes, we have a _lot_ of
Original message From: Andreas Leathley
Date: 2023-04-11 07:19 (GMT-08:00) To: internals@lists.php.net Subject: Re:
[PHP-DEV] Future stability of PHP? On 11.04.23 15:56, Jeffrey Dafoe wrote:>> So
turn off the deprecation warnings for now. They're just a heads up that>>
On Tue, Apr 11, 2023 at 9:18 AM Robert Landers
wrote:
> > You can add `#[AllowDynamicProperties]` to classes where you want to
> allow
> > dynamic properties.
>
> I don't think that will work in PHP 9?
>
>
In Niki's earliest draft, he wanted to completely remove dynamic properties
from *default*
On Tue, Apr 11, 2023, at 1:40 AM, Michael Morris wrote:
> This will be long. I've read over the Future Stability thread and taken it
> in, and decided to mull over an idea I touched on over a decade ago that I
> think might help. Also, in the interceding years the JavaScript community
> has
Essentially the same thing here. Removal of dynamic properties will be the next
big one for my team. It's the deprecations that hit huge swaths of code without
really offering much benefit that are annoying.
-Jeff
You can add `#[AllowDynamicProperties]` to classes where you want to allow
> Please double-check the source before sending questions like that to the
> list, since that information is easilly accessible
Sorry, I'll refrain from asking stupid questions in the future.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
On Tue, Apr 11, 2023, 17:18 Robert Landers wrote:
> > You can add `#[AllowDynamicProperties]` to classes where you want to
> allow
> > dynamic properties.
>
> I don't think that will work in PHP 9?
>
> --
> PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
Hi
On 4/11/23 16:18, Robert Landers wrote:
You can add `#[AllowDynamicProperties]` to classes where you want to allow
dynamic properties.
I don't think that will work in PHP 9?
As per the corresponding RFC at
https://wiki.php.net/rfc/deprecate_dynamic_properties#proposal:
Classes
On 11.04.23 15:56, Jeffrey Dafoe wrote:
So turn off the deprecation warnings for now. They're just a heads up that
behaviour is going to change in the future, with PHP 9.
I doubt you'd prefer not to be aware of the change well in advance.
Oh, absolutely. We run those "on" in our dev and QA
> You can add `#[AllowDynamicProperties]` to classes where you want to allow
> dynamic properties.
I don't think that will work in PHP 9?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On Tue, Apr 11, 2023 at 3:33 PM Jeffrey Dafoe wrote:
> > was something introduced in a time that the code being written using it
> has
> > 100% test coverage and static analysers protecting it. It's easier for
> me to deal
> > with any BC breaks of PHP 7.1 or higher than it is to deal with
>
> So turn off the deprecation warnings for now. They're just a heads up that
> behaviour is going to change in the future, with PHP 9.
>
> I doubt you'd prefer not to be aware of the change well in advance.
Oh, absolutely. We run those "on" in our dev and QA environments but off in
production.
On 11 April 2023 14:33:27 BST, Jeffrey Dafoe wrote:
>> was something introduced in a time that the code being written using it has
>> 100% test coverage and static analysers protecting it. It's easier for me to
>> deal
>> with any BC breaks of PHP 7.1 or higher than it is to deal with
> was something introduced in a time that the code being written using it has
> 100% test coverage and static analysers protecting it. It's easier for me to
> deal
> with any BC breaks of PHP 7.1 or higher than it is to deal with deprecations
> of
> PHP 5.6 or lower.
Essentially the same thing
On 11 April 2023 13:21:08 BST, Mark Baker wrote:
>We have the special constants like \MyNamespace\MyClass::class. Would you
>envisage (or is there value in) equivalent constants like
>\MyNamespace\MyFunction::function?
This has come up before, but there are two things about ::class to bear in
On 11 April 2023 13:01:08 BST, Dan Ackroyd wrote:
>On Tue, 11 Apr 2023 at 09:48, Rowan Tommins wrote:
>>
>> Similarly, I think it should be possible to "unpin" a function
>> lookup with a later definition,
>
>Can you say what the technical justification for that is?
Perhaps "should" is too
On Tue, Apr 11, 2023 at 5:40 AM Alex Wells wrote:
> On Tue, Apr 11, 2023 at 6:10 AM Deleu wrote:
>
>> I don't want to use those weird stuff, but I'm
>> doing the best I can to replace every single line of old code that has
>> been
>> written in an era that "best practices for PHP development"
On Tue, 11 Apr 2023 at 08:14, Michał Marcin Brzuchalski
wrote:
>
> Can we improve the RFC with a short description of issues on SPL autoload
> this RFC tries to address?
Sure, if you want to propose some clearer words than these:
"The spl_autoload_register() does not become an alias for
>
> We have the special constants like \MyNamespace\MyClass::class. Would
> you envisage (or is there value in) equivalent constants like
> \MyNamespace\MyFunction::function?
>
If anything, I would suggest renaming the existing constant to something
more meaningful. There is no point in adding
On 10/04/2023 14:17, G. P. B. wrote:
Dan and I would like to propose a new core autoloading mechanism that fixes
some minor design issues with the current class autoloading mechanism and
introduce a brand-new function autoloading mechanism:
https://wiki.php.net/rfc/core-autoloading
The existing
On Tue, 11 Apr 2023 at 09:48, Rowan Tommins wrote:
>
> Similarly, I think it should be possible to "unpin" a function
> lookup with a later definition,
Can you say what the technical justification for that is?
There's reasons why (imo) it's probably wrong, but I don't currently
understand what
On 11 April 2023 12:16:18 BST, "G. P. B." wrote:
>
>However, we *already* do function pinning which can result in this
>behaviour via the function cache, see the following bug which defines a new
>function via eval():
>https://bugs.php.net/bug.php?id=64346
That's not the same thing - that's
> On Apr 10, 2023, at 07:17, G. P. B. wrote:
>
> Hello Internals,
>
> Dan and I would like to propose a new core autoloading mechanism that fixes
> some minor design issues with the current class autoloading mechanism and
> introduce a brand-new function autoloading mechanism:
>
> I'm saying that the DX for writing extensions is better in other languages.
Citation needed. Java's extension API is certainly a hot mess. Python's is
fine, but ultimately has similar pitfalls to PHP's. Go's looks very nice at
first blush, but given that it's closer to an FFI than a
On Tue, 11 Apr 2023 at 09:48, Rowan Tommins wrote:
> > As a result of the pinning, function_exists() will return true for
> functions in namespaces that have been pinned to a global function.
>
> The lookup pinning seems like the right way to optimise the
> implementation, but I don't think it
On Mon, 10 Apr 2023 at 20:12, Anton Smirnov wrote:
> Hello George,
>
> I'm not sure I'm 100% correct but I think that this RFC still allows to
> call different functions for the same code, just not in the same run.
>
> Consider this pseudocode:
>
> //- funcs.php
>
> namespace My;
>
> function
On Tue, 11 Apr 2023 at 03:00, Sara Golemon wrote:
> I'm sorry. I must be misunderstanding you. Are you implying PHP has no
> native extension mechanism/API?
>
No. I can't see that reading in what I wrote.
I'm saying that the DX for writing extensions is better in other languages.
And that
Just to follow up on that, and going totally off topic, I was reading about
thanks.dev the other day.
One of our concerns is that we can easily give money to top level projects or
things we consciously add but how do you give it to all the dependencies and
the thanks.dev approach seems a good
What's meaningful in this sense?
I have a budget for supporting open source projects (back to my money v time
point) and a percentage of that is for the PHP Foundation. I'd happily pay LTS
fees we pay elsewhere (even sometimes as a safety net) to the Foundation but
believe that the money we
I'm also curious to hear whether any participants in this thread do/did
support the PHP foundation in any tangible way :D
If you treat it like an LTS provider, perhaps it's time to pay up the LTS
support fees?
Marco Pivetta
https://mastodon.social/@ocramius
https://ocramius.github.io/
On
On 10 April 2023 13:17:04 BST, "G. P. B." wrote:
>Hello Internals,
>
>Dan and I would like to propose a new core autoloading mechanism that fixes
>some minor design issues with the current class autoloading mechanism and
>introduce a brand-new function autoloading mechanism:
On Tue, Apr 11, 2023 at 6:10 AM Deleu wrote:
> I don't want to use those weird stuff, but I'm
> doing the best I can to replace every single line of old code that has been
> written in an era that "best practices for PHP development" were not what
> you and I know today.
>
I still do not
On Tue, 11 Apr 2023 at 04:41, Michael Morris wrote:
> This will be long. I've read over the Future Stability thread and taken it
> in, and decided to mull over an idea I touched on over a decade ago that I
> think might help. Also, in the interceding years the JavaScript community
> has overcome
Hi George and Dan,
pon., 10 kwi 2023 o 14:17 G. P. B. napisał(a):
> Hello Internals,
>
> Dan and I would like to propose a new core autoloading mechanism that fixes
> some minor design issues with the current class autoloading mechanism and
> introduce a brand-new function autoloading
46 matches
Mail list logo
