On Wed, Oct 23, 2024, at 11:04 AM, ericm...@php.net wrote:
> On 10/22/24 22:39, Calvin Buckley wrote:
>> After discussing it and thinking about it for a few days, I agree it's
>> not a BC break. Existing code should be fine, and larger frameworks
>> that tend to rely on reflection trickery and suc
On 10/22/24 22:39, Calvin Buckley wrote:
After discussing it and thinking about it for a few days, I agree it's
not a BC break. Existing code should be fine, and larger frameworks
that tend to rely on reflection trickery and such also tend to need
updates for newer PHP. The expectations don't rea
On Oct 15, 2024, at 2:11 PM, Larry Garfield wrote:
>
> I think folks are operating with different definitions of "BC Break".
>
> Consider:
>
> // Foreign.php
>
> class Foreign {
> public function __construct(public string $name) {}
> }
>
> // My code:
>
> $f = new Foreign('beep');
> $rProp
On Tue, Oct 15, 2024, at 19:11, Larry Garfield wrote:
> On Mon, Oct 14, 2024, at 10:27 PM, Pierre Joye wrote:
> > Hello,
> >
> > On Mon, Oct 14, 2024, 8:07 AM Bilge wrote:
> >> On 14/10/2024 01:02, Valentin Udaltsov wrote:
> >> > The problem is that in practice most of the PHP libraries consider
>
On Mon, Oct 14, 2024, at 10:27 PM, Pierre Joye wrote:
> Hello,
>
> On Mon, Oct 14, 2024, 8:07 AM Bilge wrote:
>> On 14/10/2024 01:02, Valentin Udaltsov wrote:
>> > The problem is that in practice most of the PHP libraries consider
>> > themselves to be compatible with newer PHP versions.
>> >
>> >
Hello,
On Mon, Oct 14, 2024, 8:07 AM Bilge wrote:
> On 14/10/2024 01:02, Valentin Udaltsov wrote:
> > The problem is that in practice most of the PHP libraries consider
> > themselves to be compatible with newer PHP versions.
> >
> > For instance, Symfony PropertyInfo uses `"php": ">=8.2"` const
On 14.10.2024 at 13:29, Gina P. Banyard wrote:
> The thing is, I don't even know what:
>
>> Source compatibility should be kept if possible, while breakages are allowed
>
> means here.
That refers to external extensions and SAPIs, etc. Binary compatibility
as not possible (due to API number bump
On Monday, 14 October 2024 at 12:22, Bilge wrote:
> On 14/10/2024 11:17, AllenJB wrote:
>
> > For reference, current policy on BC-breaks is here:
> > https://github.com/php/policies/blob/main/release-process.rst
>
> That policy clearly states BC breaks are only allowed in major versions,
> whic
On 10/14/24 4:37 AM, Valentin Udaltsov wrote:
First of all, I have already agreed above that PHP does not have a BC
break here. Now we are discussing the potential problems in the PHP
ecosystem and how they could be mitigated.
Then perhaps we should change the name of the thread, since the titl
On 14/10/2024 11:17, AllenJB wrote:
For reference, current policy on BC-breaks is here:
https://github.com/php/policies/blob/main/release-process.rst
That policy clearly states BC breaks are only allowed in major versions,
which flies in the face of what I read:
"Breaking changes are allow
On 14/10/2024 10:03, Bilge wrote:
On 14/10/2024 02:51, Valentin Udaltsov wrote:
Hi, Bilge!
I think that PHP should then clearly explain what is a BC break and
what isn't on a separate php.net page.
And even explain what php version constraints are safe for Composer libraries.
Some languages h
On 14/10/2024 02:51, Valentin Udaltsov wrote:
Hi, Bilge!
I think that PHP should then clearly explain what is a BC break and
what isn't on a separate php.net page.
And even explain what php version constraints are safe for Composer libraries.
Some languages have such a document:
-https://go.dev
On Mon, 14/10/2024 at 06:01, Larry Garfield wrote:
>
> On Sun, Oct 13, 2024, at 9:37 PM, Valentin Udaltsov wrote:
>
>
> > First of all, I have already agreed above that PHP does not have a BC
> > break here. Now we are discussing the potential problems in the PHP
> > ecosystem and how they could b
On Sun, Oct 13, 2024, at 9:37 PM, Valentin Udaltsov wrote:
> First of all, I have already agreed above that PHP does not have a BC
> break here. Now we are discussing the potential problems in the PHP
> ecosystem and how they could be mitigated.
Ilija and I have discussed this issue a bit.
The
On Mon, 14/10/2024 05:01, Jordan LeDoux :
>
>
>
> On Sun, Oct 13, 2024 at 5:03 PM Valentin Udaltsov
> wrote:
>>
>> On Mon, 14 Oct 2024 at 01:28, Jordan LeDoux :
>> > Backwards compatible has never, in any work I've done through my entire
>> > career, meant something like "if you take old code an
On Sun, Oct 13, 2024 at 5:03 PM Valentin Udaltsov <
udaltsov.valen...@gmail.com> wrote:
> On Mon, 14 Oct 2024 at 01:28, Jordan LeDoux :
> > Backwards compatible has never, in any work I've done through my entire
> career, meant something like "if you take old code and then update it to
> the new v
On Mon, 14/10/2024 04:07, Bilge wrote:
>
> On 14/10/2024 01:02, Valentin Udaltsov wrote:
> > The problem is that in practice most of the PHP libraries consider
> > themselves to be compatible with newer PHP versions.
> >
> > For instance, Symfony PropertyInfo uses `"php": ">=8.2"` constraint in
>
On 14/10/2024 01:02, Valentin Udaltsov wrote:
The problem is that in practice most of the PHP libraries consider
themselves to be compatible with newer PHP versions.
For instance, Symfony PropertyInfo uses `"php": ">=8.2"` constraint in
its `composer.json`.
That seems like a problem they have
On Mon, 14 Oct 2024 at 01:28, Jordan LeDoux :
> Backwards compatible has never, in any work I've done through my entire
> career, meant something like "if you take old code and then update it to the
> new version incorrectly, it doesn't work"... that seems... obvious?
>
> What exactly is the clai
On Fri, Oct 11, 2024 at 3:34 AM Rob Landers wrote:
> On Fri, Oct 11, 2024, at 12:20, Jonathan Vollebregt wrote:
>
> > A "proper" implementation won't break, but there may be subtle ways that
> "improper" implementations will break and thus it should be considered a BC
> break.
>
> This thread is
On Fri, Oct 11, 2024, at 12:20, Jonathan Vollebregt wrote:
> > A "proper" implementation won't break, but there may be subtle ways that
> > "improper" implementations will break and thus it should be considered a BC
> > break.
>
> This thread is fallaciously equating breaks in third-party librar
A "proper" implementation won't break, but there may be subtle ways that
"improper" implementations will break and thus it should be considered a BC break.
This thread is fallaciously equating breaks in third-party libraries
_when changing consumer code_, with breaks just by updating PHP.
If
On Thu, Oct 10, 2024, at 15:32, Valentin Udaltsov wrote:
> On 09.102024 at 19:20 Claude Pache wrote:
> > There is no BC break, in the sense that code that worked under PHP 8.3 (and
> > therefore use PHP 8.3 features only) will not break when run under PHP 8.4.
> >
> > Of course, code that makes a
On 09.102024 at 19:20 Claude Pache wrote:
> There is no BC break, in the sense that code that worked under PHP 8.3 (and
> therefore use PHP 8.3 features only) will not break when run under PHP 8.4.
>
> Of course, code that makes assumptions that are true when using PHP 8.3
> features only, will
On 09.10.2024 19:08, Kamil Tekiela wrote:
>
> I have to admit I understood nothing from your email, but I got
> curious about some of your words.
Hi, Kamil! I tried my best :) Thank you for your interest!
> > A readonly property is two functionalities in one: write-once and
> private set.
>
> Wh
On 10/9/24 5:01 PM, Valentin Udaltsov wrote:
While not explicitly stated in changelogs, this was a BC break,
because a changed semantic of smth that existed before is a BC break.
Since readonly was only introduced in 8.1 this wasn't a BC break. You
couldn't have a readonly property before so n
> Le 9 oct. 2024 à 17:01, Valentin Udaltsov a
> écrit :
>
> Hi, internals!
>
> Since writing https://externals.io/message/125740 I've realized that
> the major problem with aviz is actually simple but fundamental.
>
> In PHP <=8.0 this code is valid for an object of any user class:
>
> ```ph
I have to admit I understood nothing from your email, but I got
curious about some of your words.
> A readonly property is two functionalities in one: write-once and
private set.
What do you mean it is private set? Readonly only means the property
is writable once. It does not affect its visibili
On Wed, Oct 9, 2024, 9:02 a.m. Valentin Udaltsov <
udaltsov.valen...@gmail.com> wrote:
> Hi, internals!
>
> Since writing https://externals.io/message/125740 I've realized that
> the major problem with aviz is actually simple but fundamental.
>
> In PHP <=8.0 this code is valid for an object of an
Hi, internals!
Since writing https://externals.io/message/125740 I've realized that
the major problem with aviz is actually simple but fundamental.
In PHP <=8.0 this code is valid for an object of any user class:
```php
class User
{
public string $name = 'Bob';
}
$object = new User();
forea
30 matches
Mail list logo
