Re: [PHP-DEV] [VOTE] Deprecate dynamic properties
On Sun, Nov 14, 2021, 11:42 PM Rowan Tommins wrote: > On 14/11/2021 11:48, Pierre Joye wrote: > > Also I do see it as a kind of strict mode addition and the depreciation > as > > well could be strict mode only. > > > A quick reminder that PHP has no "strict mode". It has a "strict_types" > declaration, which is probably misnamed, and should be something like > "scalar_types=error" vs "scalar_types=coerce". > > yes, wrong word. > -- > Rowan Tommins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
Re: [PHP-DEV] Re: Unwrap reference after foreach
On 14/11/2021 19:49, Côme Chilliet wrote:
Le 14 novembre 2021 18:13:18 GMT+01:00, Nikita Popov a
écrit :
I have ultimately decided to withdraw this proposal.
This is sad to hear, because this is a really big footgun, which has hit me in
the past. I ended up adding a codestyle rule forcing byref foreach to be
followed by an unset to avoid this.
I understand making a special case for one syntax and not the other is
unsatisfying but I was hoping for an other outcome.
I think I agree with both of you - I agree that this is a problem worth
solving, but also that the proposed solution isn't quite the right one.
For one thing, it's just too "magic": although the current behaviour is
*surprising*, it's actually a consequence of very straight-forward
language rules; the proposed solution introduced a special case that
isn't particular easy to explain, with extra edge cases to watch out for.
One alternative solution would be to introduce block-scoped variables,
which most of the time is what people want (and expect) in *any* foreach
loop. Then the special-case for by-ref unsetting goes away, e.g.:
foreach ( $array as let $x ) {
var_dump($x);
}
var_dump($x); //null / undefined
foreach ( $array as let &$x ) { // or " $x"?
$x++;
}
var_dump($x); //null / undefined, not a reference
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: Unwrap reference after foreach
Le 14 novembre 2021 18:13:18 GMT+01:00, Nikita Popov a écrit : >I have ultimately decided to withdraw this proposal. > >Regards, >Nikita This is sad to hear, because this is a really big footgun, which has hit me in the past. I ended up adding a codestyle rule forcing byref foreach to be followed by an unset to avoid this. I understand making a special case for one syntax and not the other is unsatisfying but I was hoping for an other outcome. Côme -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] PHP 8.1 and PECL ext builds for Windows
On 14.11.2021 at 19:28, tyson andre wrote:
> With the release for php 8.1.0 stable happening Nov 25
> (https://wiki.php.net/todo/php81),
> what decision ended up being made (I couldn't tell if it was still being
> discussed from the thread)?
> To publish Windows DLLs for PECLs for PHP 8.1 after 8.1.0 stable or not to
> publish?
> I saw the proposal but didn't see any public announcement of plans,
> and usually DLLs had been published earlier.
>
> - If there are plans to get 8.1.0 working, what work is remaining (e.g. is
> there an issue tracker/list of tasks)?
> (I'm a Linux user, but I'd hope even if the windows team didn't have time,
> developers from large organizations may have time to look into those issues
> or get builds for individual extensions working, if those organizations used
> Windows and were migrating to php 8.1)
>
> https://externals.io/message/114751#114759 sounded like there were plans to
> build DLLs for PECLs with GitHub workflows instead of the current machine,
> but I'm not sure of the status of those plans.
>
> If php 8.1 DLL support was being dropped, I saw nothing communicating a
> change (or status of getting DLL builds+publishing working for php 8.1)
> in the following places:
>
> - https://news-web.php.net/group.php?group=php.internals.win
> - https://marc.info/?l=pecl-dev=2=1=dll=b
> - https://windows.php.net/ ("Where are the PECL DLLs" is an unrelated
> announcement that was resolved)
> - https://twitter.com/official_php
>
> As an arbitrary example, https://pecl.php.net/package/xdebug/3.1.1/windows
> mentions
> "In case of missing DLLs, consider to contact the PHP for Windows Team."
>
> - If DLL publishing would end up being discontinued (or delayed) for PHP
> 8.1+, the footer common to all PECLs should be updated to indicate that.
>
> I was delaying working on publishing DLLs for PECL releases until I was
> certain what the decision was,
> or if DLLs would continue to be published.
Sorry for any potential confusion! There are currently no plans to
change anything (some things *might* change in the long run, but that
would be announced). The fact that no snapshot builds of PECL
extensions for 8.1 have been yet done, is my fault. I forgot to update
the build script to do so; I've just caught up on that, so that new PECL
releases are supposed to build snapshots which would not be shown on
pecl.php.net, but could be downloaded from
Re: [PHP-DEV] PHP 8.1 and PECL ext builds for Windows
Hi internals,
> > Removing the centralized PECL builder and dependency manager would most
> > likely lead to a huge regression in the support and manageability. Right
> > now there's one place pecl.php.net to go for the non core extension builds
> > and any dependencies are guaranteed to be non conflicting. If this gets
> > decentralized, the effort is moved to the extension maintainers which will
> > most likely mean the chaos in where to get a DLL, DLL hell issues, absent
> > DLL because the configuration is hard. This will steadily lead to the
> > situation that was there before.
> >
> > IMO even keeping the basic version of the centralized approach even having
> > a sporadic chance to fix issues is a far better way to go than dropping the
> > existing achievements. Also in the long run, other approaches like moving
> > to vcpkg for deps, checking on other things like cmake and pickle might be
> > a good way, if there's a community interest. More volunteers on the
> > community side would be great in this sense, too.
>
> Good points, thank you for bringing them up! I have to fully agree that
> we should not drop the central point of distribution (i.e.
> windows.php.net). I don't think, however, that we can stick with the
> current PECL build system for long. Maybe the biggest issue is that
> extension maintainers may see automatic DLL builds as a given, or at
> least may not be able to fix things, because only few have access to the
> build machine. And even if that was not an issue, not many more would
> know where to look at. In other words, the bus factor is very low, and
> it may happen at some point in time, that no new DLLs would be built for
> *any* extension.
>
> This is why I still think it would be good to shift some of the burden
> of maintaining Windows builds to extension maintainers is a good thing.
> It is not about making their job harder, but rather about preventing
> serious issues, and also to correct expectations; extension maintainers
> might well assume that their extension is supported on common Linux
> distros, but they shouldn't *assume* it is supported on Windows as well
> (let alone that the dependency libraries have fixes for all known
> relevant security issues).
>
> Even if extensions are developed solely on Linux (and most are, as far
> as I know), they should have some Windows CI (at least doing the actual
> builds; better to run the test suite as well, of course), and that
> shouldn't be a real problem – there are several CI providers which are
> free for OSS projects. We should do our best to provide them with
> appropriate tools, so Windows CI integration can be set up as easily as
> for Linux phpize builds. That would not solve the issues regarding
> dependencies, but appears to be a reasonable first step in the right
> direction.
With the release for php 8.1.0 stable happening Nov 25
(https://wiki.php.net/todo/php81),
what decision ended up being made (I couldn't tell if it was still being
discussed from the thread)?
To publish Windows DLLs for PECLs for PHP 8.1 after 8.1.0 stable or not to
publish?
I saw the proposal but didn't see any public announcement of plans,
and usually DLLs had been published earlier.
- If there are plans to get 8.1.0 working, what work is remaining (e.g. is
there an issue tracker/list of tasks)?
(I'm a Linux user, but I'd hope even if the windows team didn't have time,
developers from large organizations may have time to look into those issues or
get builds for individual extensions working, if those organizations used
Windows and were migrating to php 8.1)
https://externals.io/message/114751#114759 sounded like there were plans to
build DLLs for PECLs with GitHub workflows instead of the current machine,
but I'm not sure of the status of those plans.
If php 8.1 DLL support was being dropped, I saw nothing communicating a change
(or status of getting DLL builds+publishing working for php 8.1)
in the following places:
- https://news-web.php.net/group.php?group=php.internals.win
- https://marc.info/?l=pecl-dev=2=1=dll=b
- https://windows.php.net/ ("Where are the PECL DLLs" is an unrelated
announcement that was resolved)
- https://twitter.com/official_php
As an arbitrary example, https://pecl.php.net/package/xdebug/3.1.1/windows
mentions
"In case of missing DLLs, consider to contact the PHP for Windows Team."
- If DLL publishing would end up being discontinued (or delayed) for PHP 8.1+,
the footer common to all PECLs should be updated to indicate that.
I was delaying working on publishing DLLs for PECL releases until I was certain
what the decision was,
or if DLLs would continue to be published.
Thanks,
Tyson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: [RFC] Migrating to GitHub issues
On Tue, Nov 2, 2021 at 3:19 PM Nikita Popov wrote: > Hi internals, > > The migration from bugs.php.net to GitHub issues has already been > discussed in https://externals.io/message/114300 and has already happened > for documentation issues. > > I'd like to formally propose to use GitHub for PHP implementation issues > as well: https://wiki.php.net/rfc/github_issues > As a heads up, voting on this RFC starts in two days. Regards, Nikita
[PHP-DEV] Re: Unwrap reference after foreach
On Wed, Nov 10, 2021 at 10:06 AM Nikita Popov wrote: > On Fri, Aug 13, 2021 at 3:28 PM Nikita Popov wrote: > >> Hi internals, >> >> I'd like to address a common footgun when using foreach by reference: >> https://wiki.php.net/rfc/foreach_unwrap_ref >> >> This addresses the issue described in the big red box at >> https://www.php.net/manual/en/control-structures.foreach.php. While this >> is "not a bug" (as our bug tracker can regularly attest), it's rather >> unexpected, and we could easily avoid it... >> > > As the discussion has died down, I plan to open voting on this RFC soon. > > I have to admit that I'm less convinced of this than I was originally, > because there's a surprising number of edge cases involved. The behavior is > more intuitive on the surface, but things get more complicated when you > look at detailed language semantics. > I have ultimately decided to withdraw this proposal. Regards, Nikita
Re: [PHP-DEV] [VOTE] Deprecate dynamic properties
On 14/11/2021 11:48, Pierre Joye wrote: Also I do see it as a kind of strict mode addition and the depreciation as well could be strict mode only. A quick reminder that PHP has no "strict mode". It has a "strict_types" declaration, which is probably misnamed, and should be something like "scalar_types=error" vs "scalar_types=coerce". Suggestions to add a more general "two modes for the whole language" approach have generally gone down in flames. Suggestions to add other declarations tend to run into discussions of namespace-scoped declares / project configuration / etc Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Deprecate dynamic properties
Hi Nikita, On Fri, Nov 12, 2021, 11:34 PM Nikita Popov wrote: FWIW I think we should always deprecate things as soon as possible, to give > people the maximum amount of awareness and time to address the issue before > the actual removal occurs. I voted no however I agree on this part, with a slight different view on how it may be done. > Meanwhile, 8.2 should include the > > AllowDynamicProperties attribute so folks can start preparing. > > > > Given how attributes in PHP work, this doesn't make sense to me. You can > already use #[AllowDynamicProperties] in your code right now, without any > special support from PHP. Only static analyzers / IDEs need to know that > they shouldn't complain about it even on versions where it does not > technically exist. I agree with other that it should be allowed by default. Also I do see it as a kind of strict mode addition and the depreciation as well could be strict mode only. It could make things too complicated, so only off by default would be an acceptable compromise to me. best Pierre
