Re: [PHP-DEV] Bug #77845 [Com]: Error in the comparaison (fwd)

[Kalle Sommer Nielsen]

Please do, it’s been long overdue

tor. 4. apr. 2019 kl. 12.44 skrev Derick Rethans :

> Hey,
>
> We have banned this "spam2" user from internals, but he's still being an
> ass on the bug system. Should I have a look at whether we can get him
> out of there as well?
>
> cheers,
> Derick
>
> --
> https://derickrethans.nl | https://xdebug.org | https://dram.io
> Like Xdebug? Consider a donation: https://xdebug.org/donate.php,
> or become my Patron: https://www.patreon.com/derickr
> twitter: @derickr and @xdebug
>
> -- Forwarded message --
> Date: Thu, 04 Apr 2019 14:37:14 +
> From: spam2 at rhsoft dot net 
> To: php-b...@lists.php.net
> X-Bogosity: No, tests=bogofilter, spamicity=0.00, version=1.2.4
> Subject: Bug #77845 [Com]: Error in the comparaison
>
> Edit report at https://bugs.php.net/bug.php?id=77845=1
>
>  ID: 77845
>  Comment by: spam2 at rhsoft dot net
>  Reported by:baklouti dot med at gmail dot com
>  Summary:Error in the comparaison
>  Status: Not a bug
>  Type:   Bug
>  Package:*Compile Issues
>  Operating System:   ubuntu 18.04
>  PHP Version:7.2.16
>  Block user comment: N
>  Private report: N
>
>  New Comment:
>
> hell post the code you are actually using instead f**g decriptions ike "
> am not using the two cases in the same time" - switch works, full stop,
> echo what $id contains really at that moment
>
>
> Previous Comments:
> 
> [2019-04-04 14:34:18] baklouti dot med at gmail dot com
>
> Yes, I try it with "case 0:" , and the same issue is happening.
>
> 
> [2019-04-04 11:21:37] ka...@php.net
>
> Because `($id === 0)` is evaluated as an expression before, meaning that
> essentially the `case` statement now looks like `case 1:`. The correct way
> to do that which you are trying to would be to make your case statement
> simply look like `case 0:`.
>
> Please refer to the documentation int the future:
> https://www.php.net/manual/en/control-structures.switch.php
>
> 
> [2019-04-04 11:10:25] baklouti dot med at gmail dot com
>
> Description:
> 
> I am testing the value of $id to do some processing. I retrieve the
> variable $id from an array ($test) and converted to integer, for the case
> that $id = 0 when using "switch" it can't be detected and if I used the
> "if" it is working fine.
> I tried with the "==" and the "===" and also not working with "switch".
> I am not using the two cases in the same time, i tested the "if" and
> "switch"
> separately.
>
>   $id = (integer)$test['id'];
>
>   if ($id === 0 ) {return 1;}
>
>   switch ($id) {
>  case ($id === 0):
> return 2;
>   
>
>
>
> Expected result:
> 
> The expected result is the bloc inside the case ($id ===0) is processed.
>
> Actual result:
> ------
> The actual result that it is passed for another case.
>
>
> 
>
>
>
> --
> Edit this bug report at https://bugs.php.net/bug.php?id=77845=1
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
> --
regards,

Kalle Sommer Nielsen
ka...@php.net

[PHP-DEV] Re: [RFC] Unbundle ext/interbase

[Kalle Sommer Nielsen]

Den fre. 22. mar. 2019 kl. 15.26 skrev Kalle Sommer Nielsen :
> https://wiki.php.net/rfc/deprecate-and-remove-ext-interbase

Given the feedback, the RFC only targets the ext/interbase extension
to be bundled and moved to PECL.

Behind the scenes, the german firebird community has reached out to me
in private with what seems to be their intention to take over the
extension, but without any further feedback from them (nor internals
participaction), even with the help of Joe and Sebastian to write a
mail in german to explain the reasoning and what an extension in PECL
may mean for them.

Given this, the RFC will go into voting on noon monday EET, April 8th
as previously planned.

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Firebird - Who are WE ...

[Kalle Sommer Nielsen]

Hi Stas

Den tir. 26. mar. 2019 kl. 00.54 skrev Stanislav Malyshev :
> That means both extensions are effectively unmaintained for over a
> decade. If this does not happen, then continuing to ship it as part of
> PHP core distribution is not doing the users any favors.

Please see this RFC I recently posted regarding this subject (and the
relevant internals thread):
https://wiki.php.net/rfc/deprecate-and-remove-ext-interbase


-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC Process: more productive conversations

[Kalle Sommer Nielsen]

Den man. 25. mar. 2019 kl. 15.30 skrev Rowan Collins :
> > It isn't the responsibility of voters to explain why they're voting no.
>
> It has actually been suggested multiple times that voters *should* justify
> their votes, so that it's clear whether a future RFC could address the
> perceived problems, or if similar RFCs are likely to receive the same votes
> against. I'm on the fence whether making it a hard requirement is
> reasonable, but I don't think we should enshrine the opposite.

As a voter and maintainer, I don't really wish to state my opinion on
every single vote I do, I think that is too much. I know it is
preferable as a maintainer, certainly, however instead I think to be
following the proposed style of etiquette, it would be recommended,
but not a hard requirement to state your reasoning for a vote. If
anything I think we should extend the voting addon for dokuwiki to
have such an option for primary voting polls.

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [RFC] Unbundle ext/interbase

[Kalle Sommer Nielsen]

Hi all

Den fre. 22. mar. 2019 kl. 15.26 skrev Kalle Sommer Nielsen :
>
> G'day internals
>
> I'd like to start the discussion for the future of the ext/interbase 
> extension:
> https://wiki.php.net/rfc/deprecate-and-remove-ext-interbase

I have updated the RFC to contain 4 proposed voting choices in form of
a secondary vote to decide on the strategy, these are:

 - Move to PECL in 7.4
 - Remove in 7.4
 - Deprecate in 7.4, Move to PECL in 8.0
 - Deprecate in 7.4, Remove in 8.0

This strategy will only be chosen if the primary vote passes.

This is based on recent feedback and again, if no serious issues comes
up, the RFC will go to voting on 8th of April, noon EET as the
original intention, which is a good 15 days away.

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Unbundle ext/interbase

[Kalle Sommer Nielsen]

Hi Peter

Den søn. 24. mar. 2019 kl. 14.39 skrev Peter Kokot :
> I'm all in for helping out here with both users using this and
> maintainers that need to worry about if this extension is even working
> ok. However, just one quick thought. The deprecation usually means
> that some functionality will cease to exist. And users usually expect
> and consider removing deprecated usage from their code and move to
> something else. Not that they will have an option to install it over
> PECL in PHP 8.0... Is this ok approach for this case? Because with
> this approach PHP is also saying quietly that PECL is a museum for
> extensions and not a place for developing them further. I might be
> completely wrong here though...

I opted for the deprecation warning as the functionality will
effectively cease to exist in php-src, we have done similar things to
other extensions (recently ext/wddx) or even ext/mysql (which did have
the ext/mysqli and ext/pdo_mysql) as alternatives, similar
ext/interbase have the ext/pdo_firebird alternative.

I see the following options to go about this extension:

1) Add a deprecation warning as the functionality will effective cease
to exist in php-src. We don't know if this extension will be taken
over if it ends up in PECL, so this is the safe bet, which is why I
opted for this initially in the RFC
2) Silently remove it already in 7.4, this is also a very viable
option, but it does not give the users to think about alternatives, We
did this for some extension in 5.6 -> 7.0, like ext/mssql. If we go
with this option, it means that there is no warnings and that whoever
picks up the extension (if any) can give them a warning free
environment.

I can amend the RFC to have these voting choices in mind if it is
preferable, similar to ext/wddx.

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Unbundle ext/interbase

[Kalle Sommer Nielsen]

Den søn. 24. mar. 2019 kl. 10.05 skrev Lester Caine :
>
> On 24/03/2019 01:42, Kalle Sommer Nielsen wrote:
> > Besides this, it has further magic behavior if the multiple
> > connections are created with the same credentials as one in the same
> > process, I'm not sure if this is fixed with Nikita's patch.
>
> But that IS the point here ... In fact many people using Firebird with
> PHP use it in 'embedded mode', where the client is actually the server
> process and explicitly blocks a second physical connection! The default
> $link is the initial default transaction and ibase_trans creates
> additional links encapsulating additional transactions on the database
> if work flow requires. The difficulty and one that PDO can never support
> is that a transaction CAN encapsulate two or more different physical
> connections and it is this which dictates that operations need an
> explicate '$link_or_trans_identifier'. Personally I use $conn and
> $transnnn explicitly to keep track of things ... but if you only open a
> single physical connection and don't add transactions then the
> 'default_link' is the only packet of workflow.
>
> ibase_connect specifically says
> "In case a second call is made to ibase_connect() with the same
> arguments, no new link will be established, but instead, the link
> identifier of the already opened link will be returned. The link to the
> server will be closed as soon as the execution of the script ends,
> unless it's closed earlier by explicitly calling ibase_close(). " It was
> this action that as broken around 7.0.3 ... and it's probably totally
> incompatible with 'thread safe'? But the firebird client can handle
> multiple calling processes - and persist connections - so the 'bug' is
> probably in how PHP and Firebird interact in a new world? We are still
> using a 20+ year old model.
>
> For a simple single transaction packet of work one opens a connection
> does the work and if the activity crashes it is rolled back otherwise it
> autocommits when finished. Yes this is magic behaviour but it's the same
> magic behaviour that it has always done even on C and Delphi platforms
> and for the vast majority of PHP processes it's all that is needed? It's
> just not politically correct today?

Your objection to the deprecation and removal of ext/interbase has
been noted, and will be recorded at vote time. I would ask that
discussion about how ext/interbase works or should work, or how it
worked twenty years ago, or how it works in Delphi is conducted
elsewhere, as this RFC is around the removal of it. Thank you


-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Unbundle ext/interbase

[Kalle Sommer Nielsen]

Den søn. 24. mar. 2019 kl. 03.11 skrev Lester Caine :
>
> (Neely forgot to fix reply address!)
>
> On 24/03/2019 00:22, Kalle Sommer Nielsen wrote:
> > mysql_connect('localhost', 'user', 'password');
> > mysql_select_db('test'); // The last created connection is implicitly added 
> > here
>
> This situation never exists in Firebird or Interbase. The ONLY way to
> connect is to a database, you can not connect to the server without
> using a database in the connection string. Each database is it's own
> file or set of files if spread across multiple disks. There is no way of
> asking a server what databases are available, you have to know
> beforehand. Although some newcomers call it a bug it's an original
> design feature.

Really Lester, really. It was a pseudo example, do I really need to be
EXPLICIT and spell everything out very specifically for you?

ibase_connect('localhost:/path/to/some/db.gdb', 'user', 'password');
ibase_query('UPDATE a_table SET a_column = 1'); // The last created
connection is implicitly added here

What happens here is that PHP retain the last connection created by
ibase_connect() and uses it as a "default" link, meaning you do not
pass a connection resource to ibase_query() afterwards.

Compare the example to:

$link = ibase_connect('localhost:/path/to/some/db.gdb', 'user', 'password');
ibase_query($link, 'UPDATE a_table SET a_column = 1'); // Explicit, as
the first parameter is a connection resource

Besides this, it has further magic behavior if the multiple
connections are created with the same credentials as one in the same
process, I'm not sure if this is fixed with Nikita's patch.

> I'll add BOOLEAN to https://phpsurgery.org/tests/ibtest.php tomorrow,
> but there are bugs in your link that don't show in the link I have been
> using :( But some of them are not bugs ...

Then use the link from the statistics page on bugs.php.net? There is
probably a fair few for PDO_Firebird too you can find on that page

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Unbundle ext/interbase

[Kalle Sommer Nielsen]

Hi Lester

Den lør. 23. mar. 2019 kl. 23.41 skrev Lester Caine :
> Thread safety is one area where the way the extension was structured
> originally may now be wrong, but the main problem with multiple
> connections is confined completely to multiple connections to a single
> database. In particular the 'default link' is actually the default
> transaction handle and additional links are simply multiple transactions
> on the one connection which I think is where some of the confusion has
> come from :( A more established Firebird user would simply start a new
> transaction, while a newbie may try to start a new connection. And in
> the past the extension has hidden that and quietly picked up the
> existing one ...

The default link should not be related to thread safety, it should be
related to the design of how database extensions used to be working.
The design was as follows (using the old ext/mysql as an example
here).

mysql_connect('localhost', 'user', 'password');
mysql_select_db('test'); // The last created connection is implicitly added here

This is the "default" link. This is some magical behavior which made
the API very easy to use, however it also created some hard to debug
situations with multiple connections. ext/interbase seems to still go
by this design which is most likely the reason to why some of the
weirdness of the extension behavior after the blind updates to
somewhat work on PHP7.

Regarding the connection and fork(), is this a problem in other
database extensions, if not, then it may be worth it for whoever ends
up picking up the extension to look at how others do this. The design
of this extension is fairly old and prone to unforeseen errors.

> "A small subset of field types are supported, anything else crashes"
> This is news to me ... is there any bug report to back it up? All the
> current data types provided by Firebird are working in the extension,
> but you may well be right that we may be better off cloning the existing
> code and building a Firebird only port going forward. The concern is the
> same one we had with windows in the past, where adding extra extensions
> does not always work reliably ... one has to provide a wrapped package
> with all the edge cases addressed. But all my use in production is using
> ADOdb to wrap the database SQL problems ...

I count 13 open bugs[1] in regards to ext/interbase thats been
reported, there are probably a ton more. Bug#74946 talks about a crash
with a type, leading me to believe that if one type can crash, then
more are very likely too.


[1] 
https://bugs.php.net/search.php?cmd=display_type=All=Open_name%5B%5D=InterBase+related=Any=30


regards,

Kalle Sommer Nielsen
ka...@php.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Unbundle ext/interbase

[Kalle Sommer Nielsen]

Den lør. 23. mar. 2019 kl. 22.59 skrev Lester Caine :
> So is there anything else which is required to bring the extension up to
> date? There is nothing above that prevents the extension doing it's job
> for the vast majority of users and even the suggestion that it is
> unusable due to Bug 72175 does not stand up to scrutiny and can now be
> fixed in 7.3 and 7.2 anyway ...

I updated the RFC with a section earlier to list some of the issues
the extension currently has. Like Joe said in the other thread, it
does bad bad things in ZTS among some of the serious issues. Even if
these things are fixed, we do not have a guarantee to have someone who
is capable of dealing with the issues at hand in the future, nor do I
see fixing bug#72175 as a reason to halt this RFC.

Like I have expressed to people who has mailed me off list (which is
inappropriate) that the extension can be taken over by anyone who
wants to from the relevant community, it just will not be distributed
by default with PHP. In fact if the extension is released on PECL, it
gives the relevant community more freedom to deal with the extension
as they deem fit and does not have the strict requirements as
extensions in the Core has. Sources and binaries are still available
with the PECL interface.

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Firebird - Who are WE ...

[Kalle Sommer Nielsen]

Den lør. 23. mar. 2019 kl. 15.59 skrev Lester Caine :
> It's lunch time here and I've just had a phone call from a client
> complaining that their site is down ... just a white screen ...
> Actually it was only a small area inside the site and I'd not picked it
> up in the several hundred pages that make up the site :( Nothing in fpm7
> log to hint at the problem - again - so I AM in something of a bad mood.
> Turned out to be part of the upgrade to get these sites working on
> PHP7.2/FB3 was missed so suggestions that something I've been using for
> 20 years does not work does not go down well!

Again this is NOT relevant to the thousands of people you are
literally spamming. This stuff belongs on Twitter, your blog or some
other kind of social media, it is NOT relevant to the development of
the PHP runtime, so keep this off the list.

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Firebird - Who are WE ...

[Kalle Sommer Nielsen]

lør. 23. mar. 2019 kl. 15.22 skrev Lester Caine :

> On 23/03/2019 12:46, Kalle Sommer Nielsen wrote:
> >> Now to get back to working out why Nikita's patch does not work in
> >> 7.2.16 ...
> > Obviously because the patch was made for PHP 7.3. Hint: If a
> > macro/function is not available in 7.2, then look at how it is
> > implemented in 7.3 and migrate it or see how other functions who do
> > similar functionality works and port it.
>
> When merging the patch with the older code I was fairly sure that it did
> exist already in 7.2 ... but until I can get php-src synced I'm having
> to manually scan for this stuff ... at the current rate hg-git will take
> 24 days so now I need another plan of attack :(


I don’t know what kind of infrastructure you have going (and frankly I do
not care, even less after what I just read from your part in the past day
or so). But you seem to be the only one with this issue and convoluted
infrastructure, but again irrelevant to the debate currently on going.

Pleased keep these rants of irrelevance off the list.

> --
regards,

Kalle Sommer Nielsen
ka...@php.net

Re: [PHP-DEV] Firebird - Who are WE ...

[Kalle Sommer Nielsen]

Lester

lør. 23. mar. 2019 kl. 15.16 skrev Lester Caine :

> On 23/03/2019 12:47, Joe Watkins wrote:
> > The thing is broken
>
> The BLOODY THING IS WORKING PERFECTLY ... what is broken is something
> that simply currently necessitates using the resource that has already
> been created rather than trying to connect again. The correct response
> to someone complaining about it is as with many other things in PHP
> simply to explain they are doing it wrong anyway.


This kind of behavior does not belong here in any possible way, and it does
not win you any points in favor. Take the rest of the evening off the
computer if you cannot handle the reality and issues that is present here
in the ext/interbase debate.
-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

Re: [PHP-DEV] Firebird - Who are WE ...

[Kalle Sommer Nielsen]

Hi

Den lør. 23. mar. 2019 kl. 14.36 skrev Lester Caine :
> We as in the people who rally around when we need to to protect the
> things we think are important. There are more people today reliant on
> elements like Firebird than there were 20+ years ago and to be honest if
> you kick the interbase driver into PECL we will carry on using it
> anyway, but YES it needs some love - from someone who can navigate
> around just how resources have been changed in PHP7. The sort of
> cooperation we had while keeping several extensions available on windows
> in the past. I'm perfectly happy that I am not the only person using PHP
> with Firebird  and reliant on it continuing to be available!

The point of putting it in PECL is for you to keep using it, if we (We
as in the PHP Development Team) did not care, it would have probably
have been removed entirely, which I personally do not believe is fair.

It is fine that you rally together, however it does not mean that we
(We as in the PHP Development Team) will change our stance unless you
bring someone to take over the extension.

To me personally, I will not halt the start of the vote unless there
is someone who stands up to take over the extension and posts some
relevant patches for it within the next 2 weeks (ish) to get it
working. We (we as in the PHP Development Team), will gladly do what
we can to welcome that aid, but after all this back and fourth and
lack of extension maintainer, I do not want to take the risk of
repeating the same loop once more, there has to be a limit.

> Now to get back to working out why Nikita's patch does not work in
> 7.2.16 ...

Obviously because the patch was made for PHP 7.3. Hint: If a
macro/function is not available in 7.2, then look at how it is
implemented in 7.3 and migrate it or see how other functions who do
similar functionality works and port it.


-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Firebird - Who are WE ...

[Kalle Sommer Nielsen]

uot; are. Like are you kidding me, honestly. Can't you just say
whether it is "we" as in:

- The Firebird community
- The Interbase community
- or a combination?
- Borland?
- Aston Tate?
- The dBase developers?

80% of this posting is more a personal blog of how you (not "we") have
been interacting with the PHP community (as in the PHP.net community
specifically). What you should have done was to reply to either me or
Dan in the RFC thread with a one liner: "I mean 'We' as in X", that
would have been it.

Please! Keep these history lessons to your personal blog instead of
internals when there is zero relevance to the topic in question.

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Unbundle ext/interbase

[Kalle Sommer Nielsen]

G'day Lester

Den fre. 22. mar. 2019 kl. 16.10 skrev Lester Caine :
> It is not that we don't want to stand up and maintain it, it has been
> impossible in recent years to get a handle on just what needs to be done
> TO maintain it. The PDO extension is in a much worse state than the main
> interbase one but both of them do their jobs as well as they can given
> that in the case of PDO it can't handle the cross database transactions,
> something that the main extension does quite happily.

Like the previous 2-3 times we have had this topic going about
removing the InterBase extension, you have referred to "we" (which I
suppose is the PHP community as a whole), however time over and time
again, no one has stepped up who has been able to maintain it. I
thought about the PDO_Firebird extension too for removal, but I wanted
to give the few possible PHP Firebird users a chance to evaluate the
situation

What do I mean by this? I mean that from a Core perspective (which I
have explained before to you personally a few years ago), but to
re-iterate: An extension in the Core that is not maintained, poses a
risk of security and maintenance required to keep the extension to a
level of quality that you (you as in the PHP community) deserve can
therefore not be up to par. On top of that, it is a burden on us Core
Developers that we cannot do anything to fix it.

> Personally I've been wasting time recently trying to keep alive sites
> that are using MySQL and the main problem with MySQL is the one thing
> that Firebird does nicely. Backup just runs as a secondary cron job
> independent of PHP while MySQL is reliant on PHP and current backups on
> some wordpress powered sites are failing because they run out of time or
> memory. I've never had a problem with loosing data with Firebird while
> I've had recover MySQL situations a few times in the last year!

That sounds like a bug in MySQL, which you should probably report to
them or look at your configuration.

> So all we are asking for is HELP with the code changes that result from
> changes to the PHP API to keep this available.

We asked for help in the past, many times in the fact if you search
the archives (and you have taken apart of the conversation every
single time), nothing has happened, therefore it is time to move past
this. The extension will put in a repository at PECL, however it is
unlike to retrieve further improvements or fixes from there unless
someone actually steps up to take over it.

We have done what we can to try call for help to keep this extension
for as long as possible, but we can only do so much for so long.

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [RFC] Unbundle ext/interbase

[Kalle Sommer Nielsen]

G'day internals

I'd like to start the discussion for the future of the ext/interbase extension:
https://wiki.php.net/rfc/deprecate-and-remove-ext-interbase

The rationale for pushing this extension out of the core is mentioned
in the RFC.

Unless there is any serious issues raised here, then I will put this
into voting on Monday 8th of April, noon EET (which is a good two and
a half weeks away). The intended voting period is set for 2 weeks,
meaning if voting proceeds, the pools will be closed around Monday
22th of April, noon EET.

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-CVS] com php-src: Fixed bug #75113: Added DatePeriod::getRecurrences() method.: NEWS ext/date/php_date.c ext/date/php_date.h ext/date/tests/DatePeriod_getter.phpt

[Kalle Sommer Nielsen]

Den man. 18. mar. 2019 kl. 07.56 skrev Sebastian Bergmann :
>
> Am 17.03.2019 um 19:37 schrieb Derick Rethans:
> > Commit:6eb83a63e1833f0991af4c5533269c8af96c
> > Author:Ignace Nyamagana Butera  Tue, 26 
> > Feb 2019 21:21:46 +0100
> > Committer: Derick Rethans   Sun, 17 Mar 2019 
> > 14:37:35 -0400
> > Parents:   f167b06d4c86c96291c21c027ba3cae22f5b5be8
> > Branches:  PHP-7.2 PHP-7.3 PHP-7.4 master
> >
> > Link:   
> > http://git.php.net/?p=php-src.git;a=commitdiff;h=6eb83a63e1833f0991af4c5533269c8af96c
> >
> > Log:
> > Fixed bug #75113: Added DatePeriod::getRecurrences() method.
>
> Why is new functionality added to PHP 7.2 and PHP 7.3?

Seconded, it should follow the same path as other functionality. We
did not merge the crc32c below 7.4 because of these are release
branches

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Proposal for deprecate alternate syntax(curly braces) for array and string access

[Kalle Sommer Nielsen]

Den fre. 15. mar. 2019 kl. 19.53 skrev Levi Morrison :
> Four thoughts:
>
>   1. I cannot think of *any* reason to separate them. If you want to
> make sure you are indexing a string, *do a type check*, not bake `{}`
> into only working on strings.
>   2. While Kalle says pretty much every codebase they've seen lately
> has used `{}` for indexing, I have *never* seen a codebase that used
> it.

Well maybe that happens to be just me, not a huge amount of usages but
there is usually some.

>   3. In any case, usage of `{}`  can be migrated to `[]` by a style
> fixer, right?
>   4. Even if we deprecate `{}`, I don't think we'd be in any hurry to
> remove it, though with an automatic fixer this seems doable, if we
> care to do it at all.

The thing is, I just don't understand the rationale to remove this
feature, what the full gain from doing so is?

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Proposal for deprecate alternate syntax(curly braces) for array and string access

[Kalle Sommer Nielsen]

Den fre. 15. mar. 2019 kl. 17.06 skrev Nikita Popov :
> I'm okay with this. This syntax has already been deprecated once, though it
> was reverted for reasons I don't remember.
>
> There are some people using this syntax to distinguish between array and
> string access. It's a nice thought, but as the vast majority of code
> doesn't make this distinction (I think the only time I saw this in recent
> years was inside some old PEAR code), it's not really a useful indicator.

I personally use it because I like to quickly tell if I am doing an
operation on a string or array, it is eye candy and makes a lot of
sense. I think if anything the two syntaxes should be decoupled
instead.

>From a usage PoV, then from personal experience (outside my own
projects), I have seen many usages of this syntax, even as late as my
current company with a growing codebase that is nearing 1.1m LoC, I
have seen this syntax used countless of times. In fact I don't think I
have been working with a code base where I have not seen this syntax
used.

I have asked fellow developers around in my community today and they
have no strong opinion on either, but do like the distinction between.

> The rarity of its use also makes it rather confusing. While $foo[$x] is
> well established as an array or string offset (or for that matter,
> ArrayObject) access and will be recognized by any programmer coming from
> any number of programming languages, $foo{$x} certainly is not, and is a
> WTF moment for people who don't happen to personally use this syntax.
>
> I'd prefer to phase out this syntax entirely and not reuse it for any other
> purpose. Reusing syntax is generally a not so good idea, because it means
> that the same syntax has different meaning in different PHP version.


For me personally it is a huge -1, if anything I would like the
string[] syntax decoupled.


-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC Draft: Comprehensions

[Kalle Sommer Nielsen]

Hi

Den tir. 12. mar. 2019 kl. 18.36 skrev Chase Peeler :
> I've never liked "developers might use it wrong" as reason to not implement 
> something, especially if hard to read/complex code is the worst impact to 
> improper use.
Me neither to be fair, but I think it is a fair consideration to have
when designing syntax. I agree with Stas reply in this thread
regarding this.

> I understand that you are talking about the syntax (which others have said is 
> still up for discussion) and not the feature itself. I still wanted to make 
> the comment above more a general response to that line of thinking.
I like the feature as it is, and if the syntax is right for it then I
would most likely vote for it if it comes to that state.


-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC Draft: Comprehensions

[Kalle Sommer Nielsen]

Hi

Den tir. 12. mar. 2019 kl. 15.49 skrev Chase Peeler :
> Everything looks weird and "non-phpish" when it's new. OO constructs weren't 
> PHP-ish at first, because PHP didn't originally support OO. Imagine "foreach" 
> didn't exist in PHP and we were still using while(list($key,$value) = 
> each($arr)) syntax.
>
> I agree that some of the examples are a bit hard to read and understand - but 
> that's only because we haven't been exposed to them.

What I mean here is that the lack of things like the parentheses makes
the code generally harder to read, imagine this for large
comprehensions as userland would certainly do things like that and you
end up with monstrosities of code that is less verbose than the
counter examples given in the RFC. I mean sure I could just rewrite a
comprehension with a lot of whitespace, but it kinda seem to defeat
the purpose of short circuited generators and I might as well just
write it the more verbose way.

I like the idea, just not the syntax because it has the potential
(along with short closures) to be annoying to read in the long run.

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC Draft: Comprehensions

[Kalle Sommer Nielsen]

Hi

Den søn. 10. mar. 2019 kl. 23.45 skrev Larry Garfield :
>
> Hello, peoples.  I know it's been discussed once or twice before on the list, 
> many years ago, but not recently.  I therefore feel OK putting forth the 
> following draft proposal for Comprehensions, aka "compact generators", in PHP:
>
> https://wiki.php.net/rfc/comprehensions

While I think believe the RFC has great intentions, I am not a fan by
any means to introduce convoluted syntaxes like this into PHP, I think
it is rather hard to read vs the gain of saving a few key strokes. I
think that both the shorthand closures and this makes PHP code
potentially even harder to read and I would prefer we did not add such
essential sugar where you need to understand the semantics very well
to understand what a piece of foreign code may do, in what order (like
the no yield example given).

One more thing that kinda "annoys" me / what I base my above statement
on is; when reading some of the example is that the code examples
given, as in the code inside a Comprehension does not look very
PHP-ish besides the $-sigil and I do not like the idea of having "two"
syntaxes for PHP where one is only available in a very narrow-,
specific context and I feel it would be prone to potential errors.

Another thing that has been mentioned by multiple people now is the
for-vs-foreach; If it is a foreach, which you mention in the RFC then
it should be so, not for. A little background on where I am coming
from here; I think it is great that we look at other languages and
technologies when designing PHP and adding more features the language,
however while I do believe it is an important point to keep cross
language consistency, I do think that consistency with PHP itself is
more important, which I believe too, is the reason for the expression
for using foreach in this context comes from (not only from my PoV).

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 7.4 Release Manager Selection

[Kalle Sommer Nielsen]

Den ons. 6. mar. 2019 kl. 11.03 skrev Nikita Popov :
>
> On Wed, Mar 6, 2019 at 6:20 AM Sebastian Bergmann  wrote:
>
> > Am 06.03.2019 um 01:18 schrieb Gabriel Caruso:
> > > I'd like to suggest Peter Kokot for this role.
> >
> > Seconded.
> >
>
> Thirded.

Fourthed.



-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] print with newline

[Kalle Sommer Nielsen]

Hi

Den søn. 3. mar. 2019 kl. 23.24 skrev Ryan Jentzsch :
>
> With semantic versioning b/c is allowed. For example version 8.0.0 vs 7.x.x
> -- version 8.0.0 could include major breaking changes (since it is a major
> version number change).  This allows a language to evolve and grow with the
> needs of the users.
> If PHP is so `rigid` that NO B/C are allowed (regardless of major version
> changes) then PHP is overtly rigid and I predict it will ultimately become
> extinct.

One very important factor for breaking BC in PHP is also the gain if
you are changing something so centric as the basic output constructs.
I don't see changing echo/print to include a new line would ever pass
due to this, however I could see (and possibly vote yes) to a new
construct that did the exact same with a new line afterwards.

These however are matters which should, by our process, be discussed
through RFCs that weights pros/cons and the overall impact and demand.
Like Johannes said; there haven't been a high enough demand for anyone
to have voiced their opinion strongly, or at least not the 11 years I
have been contributing myself or the two years I was an internals
reader before that, that I can remember.

I suggest the OP to start such a process, which can be done by
registering a user on our wiki and following the instructions for
write access to the RFC namespace.

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV][RFC] Cast in foreach

[Kalle Sommer Nielsen]

Den tor. 21. feb. 2019 kl. 14.16 skrev Chris Riley :
>
> Hi internals,
>
> I'd like to propose opening an rfc to make the following syntax legal:
>
> foreach($array as (int) $i) {}

How would this interact with the foreach-list syntax?

$data = [
["id" => 1, "name" => 'Tom'],
["id" => 2, "name" => 'Fred'],
];

foreach ($data as ["id" => $id, "name" => $name]) {
echo "id: $id, name: $name\n";
}

Having something like:
foreach ($data as (int) ["id" => $id, "name" => $name]) {

Would then make both $id and $name integers?

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] JIT

[Kalle Sommer Nielsen]

Den tir. 5. feb. 2019 kl. 20.48 skrev Niklas Keller :
> Shouldn't we introduce annotations instead of relying on doc comments?

Yeah I'm not too happy with that approach either. I would rather see
another way to do this and like you said; annotations is probably the
best way to go about it as introducing a new keyword is not very
suitable imo.

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)

[Kalle Sommer Nielsen]

Den tir. 5. feb. 2019 kl. 02.22 skrev Kalle Sommer Nielsen :
> I agree with that as long as it is without the PHP Project boundaries,

s/without/within

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)

[Kalle Sommer Nielsen]

Den tir. 5. feb. 2019 kl. 02.10 skrev Christoph M. Becker :
> In my opinion, the question “who is eligible to vote” is closely tied to
> the RFC *at hand*.  For instance, str_begins() wouldn't be much of a
> maintainance burden, and whether it should be included into the PHP core
> could very well also be decided by some of those who won't contribute to
> the implementation/maintainance.

I agree with that as long as it is without the PHP Project boundaries,
as the deciding vote is done by actual active PHP.net contributors.
For me the line about who within project can vote is up for
discussion, tho somewhere I feel it should be those with php-src karma
but I do believe anyone actively contributing to PHP as a project by
code should have the ability to vote in one way or another as a
privilege of continuous effect put into the project as a whole. I do
not believe the deciding factor should be in the hands of people
outside the project but that we as developers of the project HEARS
them and respect their voice while putting a sense of personal bias
aside like I replied to Larry in my first mail.

> On the other hand, whether to add JIT
> compilation may better only be decided by those who would have to
> maintain the implementation and who can assess related issues and
> pitfalls (I'm none of those), but not by those who only can fancy “hey,
> JIT is cool – let's have it!”  It's obviously hard to lay down
> respective rules, though.
>
> Anyhow, instead of suggesting some “general improvements/refinements” to
> the RFC process, in my opinion, we should identify *where* exactly our
> RFC process has failed, and *why* it did so.  Then we should eliminate
> the bugs (if there are any).

I think that is a healthy approach, and by reading parts of this RFC
it does sound like Zeev indeed did build on this. With the 3 current
threads we have going, despite a bit confusing, I do think we have
started to open up the can of worms that is our RFC process and slowly
work our way to see what we can do to improve that.

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)

[Kalle Sommer Nielsen]

nd have long felt
> that a more direct mechanism for user-land developers to have some influence
> on PHP would be beneficial.  (Though, yes, considerably less than the direct
> contributors working on the code base, who should still be the predominant
> constituency.)

That I do agree with. But like I mention above in the reply, I do not
believe that influence should be on the behalf of voting power. The
PHP community is large, exceptionally large and while I wish there
were ways was more open for developers to join the "conversation", I
do not see how we can start tackling that, which itself is perhaps a
topic for another thread on its own.



-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV][RFC] Allow void return type variance

[Kalle Sommer Nielsen]

Hi Wes

Den man. 4. feb. 2019 kl. 05.19 skrev Wes :
>
> Hello PHPeeps!
>
> Recent events convinced me to write this RFC :P
>
> Please have a read here https://wiki.php.net/rfc/allow-void-variance
>
> I am targeting all the supported PHP versions because this is mainly to
> placate the discontent that arised by PHPUnit enforcing its users to use
> void, so waiting 7.4 doesn't make much sense.

I don't like to suddenly change things like that in lower versions. I
would be for it for 7.4, but not merging to already active releases
branches. That is usually not how we deal with things like this.



-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)

[Kalle Sommer Nielsen]

Project Representatives, and are at least
> moderately active, much of the time.  They're responsible for reviewing,
> tracking, and approving PSR proposals, and are supposed to be active
> generalist architects.
>
> * The Secretaries are elected by Project Representatives, and keep the
> machinery working but are not involved in spec development.  They're basically
> FIG's project managers.
>
> If there's a concern about adding 50 "outsiders" to the voting rolls, I would
> propose just inviting the 12 Core Committee members to vote.  They're already
> elected in an open process to represent/work for the PHP ecosystem as a whole,
> with an eye toward compatibility, consistency, and all the same kind of stuff
> that Internals cares about.  And 12 people would not pose a threat of
> overwhelming the direct contributors, especially as a handful of them are
> already Internals contributors anyway.

Should this insane idea of allowing FIG members to vote pass, does
that also mean that the ~175 members of PHP get an equal voting right
in line with a so called Core Committee member? I doubt that. Reading
the FIG personnel page, I can spot 4 members that currently have
voting right because of their contributions to the project. Should
this RFC pass without allowing outsiders to vote, that would most
likely be down to 2 (Sara and Lukas). Besides that I spot an
additional 5 project members that can already vote or have contributed
back to PHP by code, obviously I'm only a human so my memory with the
names may be vague but there is already a presence because those
people are contributors to PHP.

In theory you already got a large say in voting on an individual
basis, even if the contributions to PHP itself is sparse.

Given the volume of people who currently votes on RFCs on average,
that would literally mean that we would increase our average voting
pool by 25%, something to consider as by then the FIG would
essentially sit with about a 20% say in whether or not something
should go in and their hands will stay clean because we as maintainers
will have to do the dirty work and that is without projects like
Laravel, Symfony and WordPress having a say, just the FIG.

What about when your Core Committee members change, that means we need
to change karma granted because your process changes? No thank you.

> (Disclosure: I am a member of the Core Committee so that would include me; I
> hope that doesn't itself turn anyone off of the idea :-), but I mention it for
> transparency and feel it would be a good approach even if I weren't.)

That itself worries me, because you are represent a part of the
community using the language, but you are not a language designer. You
are active with input on internals and RFCs etc, which I respect a
lot, but without any interest in actually writing code (I can't really
say if its true or not regarding the interest or its because of C
know-how) or because of time schedules like we all have, I don't see
why a special exception should be granted. No offense.

> Any other selection process for outside voters would, I believe, essentially
> duplicate what FIG already does.  It's better to just outsource that selection
> process to a known entity.

Any presence from an outside group means we need to have a much
different process and a lot more political babble, which quite
frankly, most other Core Developers don't really care THAT much about
unlike the FIG. Something we shouldn't have a need for, despite (to
use your own word), chaotic, nature of how internals is at times. All
we want to is to write code and enjoy it like we have done for almost
25 years this year, while the internals is no longer the "closed
gentle mans club" as it was when I joined 11 years ago, it still is
quite distinct from other OSS projects and one of the reasons why I
personally stick around, as I like that spirit the project has, which
is why I'm very protective of that as I'm certain you must have
noticed.

> Again, I'm not speaking on behalf of FIG here in any way, so other FIG members
> may have their own views on the subject.
>
> --Larry Garfield



-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Deprecation ideas for PHP 8

[Kalle Sommer Nielsen]

Den fre. 1. feb. 2019 kl. 12.34 skrev Benjamin Morel :
> You have a point here. Couldn't we add a "deprecated log" feature, that
> would log each deprecated function only once? At least we could leave an
> app running for some time, and get a curated list of deprecated features
> from the deprecated log.

I would oppose such a feature as it would make deprecations even more
redundant than disabling them. While they are annoying, they are also
a helpful message to inform our users that this functionality will not
be around, blindly ignoring it and further more giving it its own log
file that doesn't grow nearly as much seems like a bad way to solve
this.


-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)

[Kalle Sommer Nielsen]

Den tor. 31. jan. 2019 kl. 20.17 skrev Chase Peeler :
> I don't know if there is a good way to implement it, but I definitely think 
> there is value in some sort of voice being given to those that use PHP to 
> build things, but don't contribute to the actual source.
>
> I think it's important, though, to make sure that developers that are out 
> there actually developing things with PHP (not to say that contributors don't 
> belong to that group) have a voice - I'm just wondering if that needs to be 
> defined in a more formal way. One statistic I just found says that almost 6 
> million websites are running PHP7. Even if we assume that it averages out to 
> where there is 1 developer for every 100 sites, that's still 60,000 
> developers being represented by 175 voters.

I do believe that the right to vote is a privilege of actually
contributing to the project, which in our case is seen by code as we
are a scripting language project, I think that is a fair definition.

However I do believe that because it is also a privilege it should be
considered as something you earn by dedicating yourself to the
project, if you are dedicated to the project then I would assume (and
I'm certain that I speak for most core developers) when I say that
those voting for changes in PHP does it in PHP's best interest.
Because they understand the complications and impact changing things
have.

We can take an example by looking at some of the more recent change
proposals for PHP8 that goes to show that not a lot of thought about
the implications and effect changing a few functions may have. For
your open source framework that have lets say maybe 10.000 users, that
is not a big deal, but when you take that number and maybe multiply it
by 1.000 (or you can swap around the zeros), then the impact of which
we change things are set in a very different perspective. Okay we do
have procedures for how to deal with some of these things for what can
and can't go into a branch. My point here is that when you are apart
of the project and more or less integrated with it, you would also
understand the ramifications on a project of the scale.

I do not want this to sound unwelcoming or so at all, I would like
more to join the project and put effort into improving our code base.
However like Johannes said in a mail earlier in this thread, if the
maintainers (core developers) are overruled by a third party, then a
point they simply loose interest and stop contributing and the project
will begin to halt. I would feel that same way myself.

> Maybe the voice that we currently have in the form of being able to 
> participate in these discussions is enough. I'd be interested in knowing how 
> often voters are persuaded to take a position on an issue after discussing it 
> with non-voting developers - whether via these discussion lists or on other 
> mediums.

I think the AFUP did something rather interesting, which we could use
as a model; If you are not familiar with the AFUP (Association
Française des Utilisateurs de PHP), then it is the french usergroup
for PHP. Every now and then, we used to get emails from a member of
their group that would post a small summary of their thoughts
regarding a certain RFC, whether they were infavor of it or not and
potential problems they see as userland.

That I believe could work much better, as in giving external projects
or organization a way to comment on an RFC (which I would hope more
would have done instead of just being silent) about the pros and cons.
As core developers we take comments and feedback (Yes we have heard
the striking feedback about the standard library) as close as we can
to make sure that we don't just do something that would literally
render a PHP based project unusable by a change we have done.

> Maybe instead of giving all members of PHP-FIG a vote, the RFC can be amended 
> to specify that PHP related groups with a certain number of active members 
> are given a single vote. Or, instead of membership numbers, an application 
> process of some sort can be put in place for various groups to petition for 
> representation. If accepted, that group is given a single vote. A committee 
> can be put together that is in charge of addressing the applications.

Please no committee or more bureaucracy as it just makes everything so
much more political and complicated for no satisfying reason.

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] JIT

[Kalle Sommer Nielsen]

Den tor. 31. jan. 2019 kl. 19.04 skrev Zeev Suraski :
> As long as we can agree that very few actually deploy on Windows, I think 
> we're on solid grounds.
> As the JIT implementation is likely to have at least some significant 
> differences compared to Linux, I'm not sure what testing it on Windows would 
> give you.  JIT is supposed to be entirely transparent, and the performance 
> characteristics - as well as the bug patterns - are likely to be quite 
> different on Linux vs. Windows, at least in many cases.
> Is it really that important to have?

I think we can easily agree on the fact that by no means Windows is
the top candidate for production. For me personally from a project
standpoint, I believe it is something important that we can have a PHP
that is pretty much as transparent and identical no matter what
platform you are on, which is something I have tried to do myself by
implementing various Linux routines for Windows natively to make PHP
as platform independent as possible.

> I'm honestly a bit perplexed by how many people here viewing Windows support 
> as a must have, while at the same time I think we all agree PHP is very 
> scarcely found on production Windows servers, and JIT is a predominantly 
> production feature.

With above being said, then I do also agree with you here, but I would
like to have such functionality and improvements to our core system be
as global as possible, naturally I don't think its fair either to
require it so desperately upfront, but it should be a heavy
consideration with the amount of work that we all have put into making
Windows support one of the best among programming languages of similar
category.

> It'd be interesting to evaluate the cost associated with supporting Windows.  
> Bare in mind, we're proposing to vote on this as a production feature for PHP 
> 8 - which realistically means almost two years from now *at the earliest*.  
> I'm sure we'd have Windows support a lot sooner than that if we decide that 
> it's a must have.  I agree with Nikita that the key question is in fact, do 
> we or do we not want to introduce JIT in - with the main question being the 
> maintenance cost.  Let's tackle this question first, otherwise - why send 
> Dmitry (and maybe others) for doing more work (Windows support) if we are 
> likely to flush it all down the toilet?

I don't think it would be fair either to simply dismiss the idea and
many years of hard work for a detail like platform support either, and
that is not the way I hope anyone would cast their vote.

> I think that if we reach the conclusion that Windows support is a must, we 
> can condition the inclusion of JIT based on having it.  Let's first agree on 
> whether we want it in the first place.

Agreed. Naturally I would contribute in what I can to work on those
parts (Windows).


-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] JIT

[Kalle Sommer Nielsen]

Den tor. 31. jan. 2019 kl. 18.39 skrev Dmitry Stogov :
>
>
>
> On 1/31/19 7:01 PM, Nikita Popov wrote:
> > On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov  > <mailto:dmi...@zend.com>> wrote:
> >
> > Hi Internals,
> >
> >
> > I'm glad to finally propose including JIT into PHP.
> >
> >
> > https://wiki.php.net/rfc/jit
> >
> >
> > In the current state it may be included both into PHP-8, where we
> > are going to continue active improvement, and into PHP-7.4, as an
> > experimental feature.
> >
> >
> > Thanks. Dmitry.
> >
> >
> > This has been a long time on the horizon, nice to see this finally
> > moving forward :)
> >
> > Here are some initial thoughts: I think that it's best to approach this
> > issue from a cost/benefit angle. The benefits of the JIT compiler are
> > roughly (and as already outlined in the RFC):
> >
> >   * Significantly better performance for numerical code.
> >   * Slightly better performance for "typical" PHP web application code.
> >   * The potential to move more code from C to PHP, because PHP will now
> > be sufficiently fast.
> >
> > However, there are also a number of costs, on which I'll expand in more
> > detail:
> >
> > a) Maintenance: This is really my main concern. Right now there are
> > about 3-4 people who I would trust to carry out a non-trivial language
> > change, which will require touching the compiler, the virtual machine,
> > the optimizer and the persistence layer. Each of those components is
> > quite complex, in different ways. Some people who are comfortable with
> > doing VM changes will struggle with implementing optimizer changes.
> >
> > Adding a JIT compiler exacerbates this issue further. Because this JIT
> > is dynasm based, the core JIT code is essentially written in raw x86
> > assembly. This will further limit the pool of people who will be able to
> > make non-trivial engine changes. Personally, I don't have any particular
> > familiarity with writing x86 assembly, so it will likely take a while to
> > get up to speed with this code.
> >
> > b) Bugs and stability: I think that everyone is aware that the initial
> > PHP 7.3 release suffered from substantial stability issues, more than
> > new minor version releases tend to do. I think there are multiple
> > reasons for that (and we might want to start a conversation about our QA
> > processes in a separate thread), but one main contributing factor were
> > opcache optimizer bugs. Compiler optimizations are tricky and hard to
> > verify, and we often only learn about issues once the optimizer makes
> > contact with production codebases, which feature a much richer
> > collection of code patterns than our test suite. One can wonder whether
> > the relatively minor speedups we get from our optimization framework are
> > really worth having these stability issues...
> >
> > Adding a JIT compiler adds a new dimension of stability issues. Next to
> > "simple" executor bugs, and optimizer bugs, we now get additional bugs
> > in the JIT. These are probably going to be hard to debug, as we'll have
> > to drop down from our usual C-level tooling, down to inspecting assembly.
> >
> > c) Platform support: Having a JIT segregates platforms into two tiers:
> > Those that have JIT support and those that don't. While that is not a
> > problem per se, it does introduce some dangers. For example, if we
> > decide to more parts of our C code into PHP because PHP is fast enough
> > with a JIT, that will of course only be true for platforms that actually
> > have JIT support. I'm not terribly concerned about loosing out some
> > performance on MIPS, but we do need to make sure that all our main
> > platforms are supported (Windows is a must there, imho).
>
> I don't see any problems with including JIT without Windows support.
> Windows runs PHP much slower any way.

Without my usual Windows bias, I do believe it is a considerable fact
like Nikita pointed out as Windows is a first class citizen in terms
of operating systems we support. While PHP on Windows may not have the
speed that the Unix counterpart have, it is still a very important
development platform. Many developers develop on Windows and deploy on
a Unix based system, being unable to test such an important feature in
a development environment is also a large question mark.

I'm personally interested in taking a look at it (and I'm certain
Anatol does too), but simply dismissing is a no-go for me.

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)

[Kalle Sommer Nielsen]

Hi Kris

Den tor. 31. jan. 2019 kl. 18.03 skrev Kris Craig :
> Given how complex and controversial this question of restricting who can vote 
> is, I propose that it be moved to its own RFC instead of being bundled with 
> this one.  It would certainly boost likelihood of passage, if nothing else, 
> as there are a lot of good ideas in this RFC.

While that makes sense, I do believe it should be sorted at the same
time. This can be solved by secondary votes on how to approach it
within the RFC.


-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)

[Kalle Sommer Nielsen]

Hi Zeev

Den tor. 31. jan. 2019 kl. 15.44 skrev Zeev Suraski :
>
> Without further ado, an RFC that’s attempting to comprehensively solve many 
> of the issues that have plagued our RFC process since it was hastily 
> introduced in 2011:
>
>
>
> https://wiki.php.net/rfc/voting2019

I wholeheartedly disagree with the PHP-FIG special exception to who
can vote, call me biased but I do not believe it serves any purpose
and is absurd. People who actively work on PHP, should be the ones to
be able to have a choice, I think that should be reserved for any
contributor who puts effort working on PHP.

I do understand that we are the language and our work affects the
others the most. However making special exceptions for who can vote
and essentially having a say from an external source in what I in
theory need to help maintain as a PHP Core Developer is terrible. Why
not allow WordPress Core Developers to have a say instead, as their
work has a larger impact on the usage of PHP? (That was obviously a
bit of sarcasm, the last part). We are not allowed to vote at their
individual projects features (nor do we need to have a say if we are
not actively involved in the development of said projects or
organizations) and I stand very strongly behind that belief.

Besides this, it also creates uncertainty about who elects such, and
simply should be dropped from the voting RFC as it was already fairly
unclear from the original one.

The contributors appendix also lists ChangeLog, SVN Migration etc,
something to keep in mind if this RFC is moved forward to filter the
list.


Do I understand the PHP Packaging Decisions right that it requires to
vote for a timeline for each version? I remember we have different
opinions raised regarding the time to a new major version (should we
have 7.4 vs go to 8.0, same for the 5 to 7 transition back then
regarding a 5.7). This is the only issue I can think of and should be
changed to requiring a vote if there is a dispute in regards to what
the next version should be. As I don't really wanna vote just to vote
for each of the minor versions of 8 once a year when its the most
logical reason to go to 8.1 from 8.0, and so on until we reach the
point where the next major is considerable.


I think changes like the requiring a patch for RFCs is a very welcomed addition.

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Issue tracker - "Block user comments" abuse and alternatives

[Kalle Sommer Nielsen]

Hi

Den man. 7. jan. 2019 kl. 01.38 skrev Philippe Cloutier :
>
> Hi,
> I reported a bug on the issue tracker in https://bugs.php.net/bug.php?id=53255
> Hannes "bjori" Magnusson later marked the ticket as "Not a bug", insulting 
> myself (and apparently other contributors who had previously reported the 
> same issue) at the same time. Peter Kokot later confirmed the issue, which is 
> caused by an obvious concurrency bug, as can be seen in 
> https://bugs.php.net/bug.php?id=66653
>
> In order to ensure this contempt is over, I meant to warn the responsible by 
> commenting in #53255. Unfortunately, that very same contributor went as far 
> as "blocking user comments" in this ticket, and the tracker considers me as a 
> "user", so I cannot do that. Therefore:
> 1. Can someone with sufficient permissions unblock commenting in #53255?
> 2. While no security at all was needed  in this case, in general, soft 
> security support minimizes the temptation to put in place "hard security". 
> Does the ITS allow hiding comments considered as useless, as Bugzilla allows, 
> instead of blocking?

I re-opened the issue. As a note, please keep issues like this to the
webmaster list as internals is purely language development.

Thank you!


-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Inconsistent float to string vs. string to float casting

[Kalle Sommer Nielsen]

Den ons. 26. dec. 2018 kl. 16.53 skrev Nikita Popov :
>
> On Wed, Dec 26, 2018 at 4:48 PM Christoph M. Becker 
> wrote:
>
> > Hi!
> >
> > Regarding the decimal separator (aka. decimal point), the behavior of
> > casting float to string is inconsistent with casting string to float.
> > While the former regards the current locale, the latter always expects a
> > decimal point regardless of the locale.  This breaks round-trips for
> > locales which use something else than a dot as decimal separator (e.g.
> > German, which uses a comma), for instance:
> >
> > $float = 1/3;  // float(0,33)
> > $string = (string) $float; // string(16) "0,33"
> > $float = (float) $string;  // float(0)
> >
> > As for me, the question is not *if*, but rather *when* and *how* this
> > inconsistency should be resolved.  Regarding the *when*, it seems to me
> > we have to wait for the next major version, i.e. PHP 8.  Regarding the
> > *how* I tend to prefer the non-locale aware behavior, i.e. float to
> > string conversion should always produce a decimal *point*.  Users still
> > can explicitly use number_format() or NumberFormatter if they wish.
> >
> > Thoughts?
> >
>
> Yes, please. Locale-sensitive library functions are bad enough, but core
> language behavior should *never* be locale-sensitive.
>
> I'm definitely in favor of making float to string casts locale-independent
> in PHP 8.

I'm in the same boat here. I remember we had some interesting
behaviorial differences on a language level too[1] (which seems to
also have maybe resurfaced after reading the newest comments).

[1] https://bugs.php.net/bug.php?id=18556



-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: patch for imap bug 77153

[Kalle Sommer Nielsen]

Den ons. 21. nov. 2018 kl. 06.13 skrev Pierre Joye :
> Btw, is imap on the list to deprecate in 7.x + kill in 8.x? It is really
> not maintained well, both c-client and the ext. Would it be possible to
> consider it?

I remember we have spoken about this in the past and it seems that
everytime it comes up, is the argument that we don't provide a real
mail alternative. I mean sure there is lots of userland based
implementations and all, but I still think that PHP should provide
something out of the box, but I do agree that at one point, the
security concerns will start to vastly outweight the unmaintained
library, but its really something that should be discussed for a
future release.



-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Idea for better function callbacks (another syntactic sugar)

[Kalle Sommer Nielsen]

Den fre. 26. okt. 2018 kl. 18.03 skrev Levi Morrison :
> In my opinion "ideal" here is that our symbol tables are merged, so
> referring to "trim" in any context will resolve to at most one symbol,
> *and* that we also have a short-closure syntax for times when there
> isn't a *perfect* function to use.
>
> In the next version of PHP I would really like to see some warnings
> for when symbol names get re-used so that in the future we can merge
> them with less of a BC break.

I like that idea a lot tbh, but I do worry a lot about the lookup time
if we end up with a gigantic hashtable to hold all the symbols and the
implications it has. In most contexts we know (based on the syntax)
what we are looking for, however as it currently stands then it would
not be clear wether to look for the constant "trim" or the procedural
function "trim" in the example given, and if thats all the same, I can
see that many things not utilizing this could be slower for no good
reason (at least in my honest opinion). However I don't know if there
is something sneaky we can do here.



-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Idea for better function callbacks (another syntactic sugar)

[Kalle Sommer Nielsen]

Den fre. 26. okt. 2018 kl. 17.43 skrev Larry Garfield :
> I believe the proposal for short lambas (which should get resurrected at some
> point) would handle this case well enough as well as help a dozen other
> things.  To wit:
>
> array_filter($names, |$x| ==> trim($x))

I still fail to see why it would be considered to have that over a
perfectly encapsulted string for a callback, using a lambda/closure is
just an extra runtime call for syntax sugar, that seems poor in my
eyes.

What would be ideal here, would be for functions to be first class
citizens in callback contexts, like in C to avoid the quotation,
however it clashes with constants. A hack you can do in userland could
be something like:

const trim = 'trim';
array_filter($names, trim);



-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Alias openssl_random_pseudo_bytes() to php_random_bytes_throw()

[Kalle Sommer Nielsen]

Hi Sammy

Den fre. 19. okt. 2018 kl. 02.38 skrev Sammy Kaye Powers :
> 4) We get to consolidate our CSPRNG code in one place. This would make
> it nice to be able to upgrade all the CSPRNG code to libsodium's
> CSPRNG if we choose to in the future for example.

I would prefer this, any instead of making it an alias or something,
then just straight down deprecate it instead seems like a more
flawless option to me.

> The change I'm proposing would be to:
>
> 1) Make openssl_random_pseudo_bytes() return bytes from
> php_random_bytes_throw() causing the function to fail closed and never
> returning false.
> 2) Deprecate the usage of the second pass-by-reference parameter and
> remove in PHP 8.0. Until then, it always sets the value to true.
>
> Do you think this kind of change would warrant an RFC?

It would.



-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] ext/dba: drop support for Berkeley DB < 4

[Kalle Sommer Nielsen]

Hi Christoph

Den lør. 6. okt. 2018 kl. 15.50 skrev Christoph M. Becker :
>
> Hi!
>
> ext/dba still supports Berkeley DB 2 and 3, and offers an emulation
> layer for version 1 databases.  However, Berkeley DB 4 has been released
> in 2001, and Berkeley DB 3.3.11, the final release of the 3.XX
> versions[1], has been released on 2001-07-12.  It doesn't seem to make
> much sense to support these old version anymore.
>
> Unless I'm missing something, I suggest to drop support for Berkeley DB
> < 4 as of PHP 7.4.0.
>
> [1]
> <https://www.oracle.com/technetwork/products/berkeleydb/downloads/index-082944.html>

I think this is generally a good idea to look at such. Perhaps we
should do a larger, collective effort to get an idea of what things we
support that is way outdated and such and up our requirements at the
same time. There seems to have been a trend in that direction in the
past year or so and I think its way overdue that we begin to remove
crufts like that.

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] RFC Result: Make the hash extension always available

[Kalle Sommer Nielsen]

Greetings hackers

I'm happy to announce that the RFC "Always available hash extension"
have been accepted with a 30-0 vote.

I apologies for the initial poorly written date in the voting
announcement email. Thank you all for voting!

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] RFC Vote: Make the hash extension always available

[Kalle Sommer Nielsen]

Hi

After a two week period without any objections to the RFC, I have gone
ahead of opening the voting polls for making the hash extension a
permanent part of PHP.

RFC: https://wiki.php.net/rfc/permanent_hash_ext
Vote: https://wiki.php.net/rfc/permanent_hash_ext#vote

This vote will run for two weeks from today (and close on 19/09-2018
around noon UTC+1). Since this change impacts a larger set of PHP
itself, the vote required for this to pass is 2/3.

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Unbundle libsqlite3?

[Kalle Sommer Nielsen]

Hi

Den man. 17. sep. 2018 kl. 15.16 skrev Christoph M. Becker :
>
> Hi!
>
> We bundle an unmodified libsqlite3 for at least two years.  Since then
> all updates go into any dev, alpha and beta releases, while security
> patches (usually backports from libsqlite3) go into stable branches.
>
> ext/sqlite3 requires libsqlite ≥ 3.3.9[1] which has been released on
> 2007-01-04[2] (i.e. more than eleven years ago!).  ext/pdo_sqlite has no
> specific version requirement; there is a check for sqlite3_open()[3]
> which I believe is available since 3.0.0.
>
> So is there any particular reason why we still bundle libsqlite3?
>
> [1]
> <https://github.com/php/php-src/blob/php-7.3.0RC1/ext/sqlite3/config0.m4#L37-L47>
> [2] <https://sqlite.org/oldnews.html#2007_01_04>
> [3]
> <https://github.com/php/php-src/blob/php-7.3.0RC1/ext/pdo_sqlite/config.m4#L55-L58>

I don't think there is any paticular reason for bundling it anymore,
at least not from the Windows side of things where we should be easily
able to adapt the build system to link to it instead of building the
bundled version. (Anatol cc'ed)


-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: RFC Proposal: Make the hash extension always available

[Kalle Sommer Nielsen]

Den tir. 4. sep. 2018 kl. 12.20 skrev Christoph M. Becker :
> That appears to be sensible.  Anyhow, *if* we do this, we also should
> move the MD5, SHA1 and CRC32 code from ext/standard to ext/hash (MD5 and
> SHA1 is currently dead code in ext/hash, and the CRC32 implementation
> seems to be duplicated).  We should also have a look at crypt_sha256.c
> and crypt_sha512.c (of ext/standard) which likely duplicate some code
> already available in ext/hash.

Those makes a lot of sense to do, and definitely something we should
if this RFC passes


-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] RFC Proposal: Make the hash extension always available

[Kalle Sommer Nielsen]

Gday fellow hackers

I just posted an RFC and set it up for discussion[1], this proposes to
make the ext/hash extension always enabled, similar to that for date,
spl & pcre.

Comments are welcome. I intend to start voting in 2-3 weeks time,
should there be no critical issues in regards to this RFC.


[1] https://wiki.php.net/rfc/permanent_hash_ext

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 7.3 branched

[Kalle Sommer Nielsen]

Den tir. 31. jul. 2018 kl. 22.57 skrev Christoph M. Becker :
> I've never tried pickle, and I have no idea about its status and
> usability (after all, further development appears to have been mostly
> ceased[2]), but still it might be the best way to move forward.
>
> [2] <https://github.com/FriendsOfPHP/pickle/graphs/contributors>

I noticed that when glancing over it before I sent my mail. Either way
I think this is something we should have a look at, or at least invest
the time into something so we can ease our pain for releases. Not that
I have anything in mind for PEAR in paticular, but it seems odd for us
to still rely on something that seems essentially dead.


-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 7.3 branched

[Kalle Sommer Nielsen]

Den tir. 31. jul. 2018 kl. 17.58 skrev Christoph M. Becker :
> [1] <https://github.com/pear/pear-core/commit/04b4624>

Off-topic: Perhaps its time to look at alternatives and unbundle pear
instead of only seeimly (at a quick glance) keeping it alive for newer
PHP compatibility, which seems to have the main case for the last
couple of years. We had issues with pear releases at close to every
larger release in close to 10 years.

We have alternatives like pickle[1] thats fairly new or I'm sure we
can develop a tool capable of managing PECL extensions.

[1] https://github.com/FriendsOfPHP/pickle

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Unifying logical operators

[Kalle Sommer Nielsen]

Den tir. 10. jul. 2018 kl. 21.08 skrev David Rodrigues :
>
> I think that "or" could be removed if PHP could supports inline conditionals 
> like:
>
> die() if !$connected;
> throw Exception() if fail();
> $x = $y if (z() && w());
>
> Or "when": die() when !$connected;
>
> It seems more clear than $connected or die().

I in fact find that more unreadable as you first got to dig through
the error handling before you actually get to the logic that triggered
it.


-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Unifying logical operators

[Kalle Sommer Nielsen]

Den tir. 10. jul. 2018 kl. 20.22 skrev Larry Garfield :
> "do() or die()" code is/was very common in example code, tutorials, and other
> intro material because it means you don't need to think about error handling.

I personally wanted to extend this syntax but I never got around to it
to support: "do() or throw new Exception(...);", tho its just a code
style over: "if(!do()){ throw new Exception(...); }"



-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] On not rushing things at the last minute

[Kalle Sommer Nielsen]

Den tir. 10. jul. 2018 kl. 17.26 skrev Dustin Wheeler :
> I'm relatively new to all of this. I think it's a bit strange to
> earmark a minor release as deprecation-only, but I also wasn't around
> for the last major upgrade to see discussion (was 5.6 the focus of
> many deprecations?)

Afair then it was proposed to have PHP 5.7 as a deprecation/migration
friendly release but we ended just rolling with PHP7 and the migration
was merely flawless. Personally I don't like the idea of such type of
releases either, I think they make sense on paper but reality is also
that we have a branch to support for years to come as to our current
release policy.


-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3

[Kalle Sommer Nielsen]

Den man. 9. jul. 2018 kl. 21.22 skrev David Zuelke :
> Keep in mind you can do phpversion("extensionname"), so that function
> at least can't be removed, as the constant doesn't provide the same
> functionality.

Sure, but almost all of the core extensions return PHP_VERSION anyway
(thanks to Peter K.) and the information is still available with echo
(new ReflectionExtension('extensionname'))->getVersion(); and I doubt
there is a massive usage so the impact is very minimal and therefore I
believe its a fair compromise.


-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3

[Kalle Sommer Nielsen]

Den søn. 8. jul. 2018 kl. 23.42 skrev Christoph M. Becker :
> Sorry, that there has not been any decision yet.  However, Sara
> suggested that this decision is not solely up to the RMs[1], and I
> wouldn't know how to decide it then[2], since there has been at least
> one objection[3].
>
> [1] <https://externals.io/message/102333#102613>
> [2] <https://externals.io/message/102333#102648>
> [3] <https://externals.io/message/102333#102640>

I have a few concerns that if we push the GA date it will be too close
to christmas and would rather see the Typed Properties RFC as apart of
the next series of PHP personally. On the bright side, it does allow
us more time for a potential PHP8.


-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3

[Kalle Sommer Nielsen]

Den søn. 8. jul. 2018 kl. 23.18 skrev Nikita Popov :
> I assume that we're going forward with the addition of the alias, so I moved 
> the FILTER_SANITIZE_MAGIC_QUOTES deprecation from the PHP 7.3 to the PHP 7.4 
> deprecations RFC.

I implemented the 'add_slashes' filter to master so we should all be
good at that department. I will take care of updating the portion of
the 7.4 RFC to mention this new addition.



-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Typed Properties

[Kalle Sommer Nielsen]

Den lør. 7. jul. 2018 kl. 10.47 skrev Björn Larsson :
> I leave this to the judgement of the RMs. I have no opinion myself,
> besides I think it's a good idea to keep the GA date.

I agree, and an additional few weeks will make the release date very
close to the holidays, I think late November/early December is the way
to go about this.

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3

[Kalle Sommer Nielsen]

Den tor. 5. jul. 2018 kl. 22.51 skrev Kalle Sommer Nielsen :
>
> Den tor. 5. jul. 2018 kl. 22.46 skrev Nikita Popov :
> > Sounds reasonable to me. My only question would be when we would start 
> > emitting the deprecation notice. I'm not a fan of deprecating things in the 
> > same release as the alternative is introduced, so I would suggest to add 
> > the new alias in PHP 7.3 and perform the deprecation in PHP 7.4.
>
> I agree here, I don't think a simple constant would hurt too much to
> add outside the scope of this RFC so I will go ahead and do soonish
> that if no one else objects. Then we can move the section to the 7.4
> Deprecation WIP RFC.

I wrote a quick patch[1] for this (look away from the deprecation
warning), which basically adds a new alias 'add_slashes', this seemed
like the easiest way to go about it. While looking into ext/filter it
seems there are no implementations for INPUT_SESSION and
INPUT_REQUEST. I doubt there is any intention to implement these so
they could be potentials for adding a deprecation for (or simply
removal as they just yield an E_WARNING when used anyway)[2].


[1] https://gist.github.com/KalleZ/cce52f230d599501373b15729ec85bfc
[2] 
https://git.php.net/?p=php-src.git;a=blob;f=ext/filter/filter.c;h=56c93199f0bf4f713eeb81c0dfddb910b02b9618;hb=HEAD#l547


-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3

[Kalle Sommer Nielsen]

Den tor. 5. jul. 2018 kl. 22.46 skrev Nikita Popov :
> Sounds reasonable to me. My only question would be when we would start 
> emitting the deprecation notice. I'm not a fan of deprecating things in the 
> same release as the alternative is introduced, so I would suggest to add the 
> new alias in PHP 7.3 and perform the deprecation in PHP 7.4.

I agree here, I don't think a simple constant would hurt too much to
add outside the scope of this RFC so I will go ahead and do soonish
that if no one else objects. Then we can move the section to the 7.4
Deprecation WIP RFC.

All in all I think its a much cleaner migration path



-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3

[Kalle Sommer Nielsen]

Den tor. 5. jul. 2018 kl. 22.22 skrev Stanislav Malyshev :
>
> Hi!
>
> > After looking into this, I think that FILTER_SANITIZE_MAGIC_QUOTES may be a
> > legitimate filter, which just has a bad name. Next to other filters that
> > perform htmlspecialchars and urlencode, it makes sense that there is also a
> > filter that performs addslashes. Maybe we should just rename this filter to
> > something which is not tainted by the "magic quotes" terminology?
>
> Makes sense. There's nothing specially evil in addslashes if used in
> appropriate context. Also, for those that are newer to PHP, "magic
> quotes" means very little. So it's a bad name from various perspectives.
> Having something like FILTER_SANITIZE_ADD_SLASHES would be fine.

Thinking some more about it, I kinda agree with the sentiment and I
think a rename is much better as it doesn't really hurt. We could add
an alias constant instead and provoke an E_DEPRECATED if the old one
is used (given we don't give the filter the same numeric value).

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Deprecate and remove continue targeting switch

[Kalle Sommer Nielsen]

Den tor. 5. jul. 2018 kl. 00.15 skrev Yasuo Ohgaki :
> Since the issue is incompatibility between current "continue" and "break",
> how about provide a tool replace "continue" to "break" where it is
> applicable.
> (Raise error for invalid "continue" usage also. This would be a bug most
> likely.)
>
> Then there wouldn't be compatibility issue anymore.

I like the idea of a tool for such, but I think its better to
implement it in some of the static analyzer projects like PHPStan and
the like to catch these.



-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3

[Kalle Sommer Nielsen]

Den søn. 24. jun. 2018 kl. 18.47 skrev Nikita Popov :
> If you have a minor deprecation in mind, but were too lazy to write an RFC
> for it, please write me a mail until tomorrow, so that it might be included
> as part of this proposal. As time is limited I don't want to include
> anything larger or controversial in this RFC though.

I took the liberty and added the FILTER_SANITIZE_MAGIC_QUOTES to the
RFC so we may once and for all get rid of magic_quotes.


-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3

[Kalle Sommer Nielsen]

Den tir. 26. jun. 2018 kl. 22.01 skrev Nikita Popov :
> Thanks for adding it. Unless there is a particular reason to rush here, I'd 
> suggest to follow the usual process and formally deprecate the option prior 
> to removal.

I don't think theres a need for a rush here, tho I wasn't sure how you
prefered we handled the ini directive deprecation, I thought adding it
to main.c would be too "noisy".

> As a clarification, what is the alternative to using this ini setting? I 
> guess you can just explicit set the DB2INSTANCE env var, but that probably 
> has the same issues. Is there a "correct" way to do this? (Sorry if it's 
> obvious, I'm not familiar with ODBC.)

I'm not too familiar with it either, I just remember it from way back
then when I began the crusade to kill old functionality in the 5.3
development days. I don't think there is any other alternative than
setting it manually, which still creates the same issues as what it
already does not but forces our users to be explicit about it. I
personally don't like such magic behind the scenes.

As for any correct way, I don't think there is any other, given how
the ibm_db2 pecl package mimics the same behavior as pdo_odbc does,
but then again the IBM folks have not been the fastest to update their
extensions, so maybe there there is a new way to do it now but I doubt
it. I don't really have the interest to dig too much into it either.

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3

[Kalle Sommer Nielsen]

Den tir. 26. jun. 2018 kl. 20.16 skrev Nikita Popov :
> Feel free to add this one to the RFC, if you know what the background for the 
> deprecation is. Given that the manual already marks it as deprecated for so 
> long, this seems like a mere technicality.

I added the pdo_odbc.db2_instance_name to the RFC including 2 options
which is up to you to decide for with the relevant patches included.

> Given the recent discussions about having a PHP 7.4 release for additional 
> deprecations, I'm going to punt on the rest. While they may be no-brainers to 
> you and I, a lot of those are actually quite controversial (e.g. there was an 
> RFC to deprecate b' in 7.2 and it was declined -- go figure!)
>
> I'd suggest that you already open up the next deprecation RFC, to make sure 
> these are not forgotten. Some of them should probably get separate proposals 
> altogether (especially the var interpolation syntax).
>
> Nikita

I agree that a lot of them are controversial, and perhaps its a good
idea to start flesh them out for our users and fellow contributors
already now. I began a draft based on your 7.3 RFC for 7.4[1]. Ps I
took the liberty of adding your name as the RFC author.

[1] https://wiki.php.net/rfc/deprecations_php_7_4


-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3

[Kalle Sommer Nielsen]

Hi

Den søn. 24. jun. 2018 kl. 18.47 skrev Nikita Popov :
> If you have a minor deprecation in mind, but were too lazy to write an RFC
> for it, please write me a mail until tomorrow, so that it might be included
> as part of this proposal. As time is limited I don't want to include
> anything larger or controversial in this RFC though.

As suggested in the past, I would like to add the following to this
list (if its not too late):

 - The (real) type-cast and its function, is_real(). There doesn't
seem to be any support for reals in settype() anyway (side note: in
the implementation of settype() it claims "double" is deprecated)
 - Function variants that already exists as constants, php_sapi_name()
> PHP_SAPI, pi() > M_PI, phpversion() > PHP_VERSION etc
 - enable_dl ini directive, as dl() is only operational for CLI and Embed anyway
 - pdo_odbc.db2_instance_name ini directive, its been marked as
deprecated and mentioned in the manual since PHP 5.1.11 that it will
*certainly* be removed in the future
 - The 'b' constant string prefix, its not used and was meant as to
make code ready for PHP6, should the time come where we want to add a
feature that uses this, we can always re-add it

Other things thats been suggested by others in the past:

 - Second parameter of spl_autoload() and its associated function
spl_autoload_extensions()
 - hebrevc() -- same as hebrev() + nl2br(), perhaps even deprecate
hebrev() too (see next one)
 - convert_cyr_string() -- Point to mb_convert_encoding() / iconv
 - Remove get_magic_quotes_gpc(), not been working for what, 5+ years now?
 - allow_url_include ini option, this can lead to all kinds of
security complications anyway
 - The alternative string interpolation syntaxes (${varName},
${varName['offset']}, ${expr}) and make them more consistent
({$varName}, {$varName['offset']}, {${expr}})
 - The historial parameter handling that works both ways for
implode(), should be unified to match that of explode()

I could probably think of more, but thats all I got for now. I can and
will of course help produce the relevant patches should it be needed
for most of these things.

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 8 next?

[Kalle Sommer Nielsen]

Hi

Den søn. 24. jun. 2018 kl. 02.59 skrev Levi Morrison :
> Neither JIT nor FFI require backwards compatibility breaks in
> language. I don't think either of those particular features would
> substantially break the C API either. If these are the motivations for
> PHP 8 then I strongly object.

I agree with the objection, however they are also a major selling
point for a major version which I think is something worth keeping in
mind.


-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] What to do with image2wbmp()?

[Kalle Sommer Nielsen]

Hi

2018-04-05 14:04 GMT+02:00 Christoph M. Becker <cmbecke...@gmx.de>:
> Hi everybody!
>
> <https://bugs.php.net/73317> is still unresolved, and I'm not sure how
> to resolve it.
>
> TL;DR: the $threshold parameter of image2wbmp() is supposed to specify a
> *brightness threshold* for the required black and white conversion of
> the image.  However, as of PHP 5.0.0 it is actually interpreted as the
> *foreground color*; all other colors are treated as background.  This
> makes image2wbmp() basically identical to imagewbmp().
>
> Any suggestions on how to proceed here?

If thats the case that its basically identical, then a PHP_DEP_FE
should be sufficient for image2wbmp() and a removal in future version,
given its a rarely used function and migration is easy, even 7.4 could
potentially be fine for removal.



-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 7.3 Release Manager Selection

[Kalle Sommer Nielsen]

2018-04-12 23:56 GMT+02:00 Sara Golemon <poll...@php.net>:
> Please put your name forward here if you wish to be considered a candidate.
> An initial todo page has been added to the wiki and contains
> provisional dates for GA and pre-releases.

Dream team wish: Nikita & Christoph


-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Mailing list moderation

[Kalle Sommer Nielsen]

Hi Derick

2018-04-04 20:42 GMT+02:00 Derick Rethans <der...@php.net>:
> Hi,
>
> "rhsoft" continues their aggressive behaviour on the bug tracker still
> too. One recent illustration is
> https://bugs.php.net/bug.php?id=76184=1
>
> Do we have any methods to ban people from there too?

Sadly we do not as far as I'm aware of, the best thing we could do is
to add rhsoft or similar to the spam keywords, but even that is easily
bypassable.


-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] definition of zendparse

[Kalle Sommer Nielsen]

Hi Ryan

2018-02-25 3:42 GMT+01:00 Ryan McCullagh <m...@ryanmccullagh.com>:
> I can't find this anywhere after a compile of master. `grep -r -n 'zendparse' 
> *`. I see that there are declarations of zendparse, but there is no 
> definition as far as I can see. How is this happening?

This comes from the Zend/zend_language_parser.y file in its generated
form, the yyparse name is set to zendparse (through #define yyparse
zendparse)

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV][RFC][DISCUSSION] Deprecate the backtick operator

[Kalle Sommer Nielsen]

2018-02-12 15:38 GMT+01:00 Eli White <e...@eliw.com>:
> I'll chime in on the "What evidence do you have that this is not
> widely-used" ... in fact, I have seen through my PHP career this used very
> regularly, and training/workshop/class sessions at conferences still
> regularly teach this as the 'standard way' to handle shell commands.
>
> So I think that this would have a huge impact on existing code, and I am
> similarly a huge -1.  Is it funky that random backticks cause a shell
> action to happen?  Yes.  But there are a million funky things about PHP,
> and we strive for backward compatibility when at all possible.  And there
> is no direct gain/need to remove this feature.
>
> Eli

Same thoughts here, -1 on deprecation. I prefer to use backticks over
shell_exec() when writing code that does something simple.


-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RE: Requesting php-src Karma

[Kalle Sommer Nielsen]

On 26 Jan 2018 21.02 <20%2018%2021%2002>, "Anatol Belski" 
wrote:

Hi,

> -Original Message-
> From: Thomas Punt [mailto:tp...@hotmail.co.uk]
> Sent: Thursday, January 25, 2018 11:41 PM
> To: PHP internals list 
> Subject: [PHP-DEV] Requesting php-src Karma
>
> Hi internals,
>
>
> I'd like to request for php-src karma for my account (tpunt) in order to
help
>
> with the handling of PRs on GitHub. Having been contributing to PHP for
>
> a few years now, I feel like I've got the hang of things well enough to
make
>
> more of an impact to the project now.
>
I've first seen Thomas' contributions over two years ago at his early
efforts to document PHP 7.0 features. At least from that point on, he made
contribution to both doc and the core codebase through various pull
requests and reviews. Based on his continuous and prudent participation,
I'd see it as adequate to provide Thomas with the direct access to php-src.
He is a valuable PHP contributor in point of fact.

Regards




Anatol

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php+1

Re: [PHP-DEV] return values of socket_recvmsg

[Kalle Sommer Nielsen]

Hi Sam

2018-01-25 23:11 GMT+01:00 Sam Ding <samd...@ca.ibm.com>:
>
> The test case  ext/sockets/tests/socket_recvmsg.php  has following output
> on x86_64:
>
> ===
> ...
> 1 Array
> 2 (
> 3[name] => Array
> 4(
> 5[family] => 10
> 6[addr] => ::1
> 7[port] => 7001
> 8[flowinfo] => 0
> 9[scope_id] => 0
> 10)
> 11
> 12[control] => Array
> 13   (
> 14[0] => Array
> 15   (
> 16[level] => 41
> 17[type] => 50
> 18[data] => Array
> 19   (
> 20[addr] => ::1
> 21[ifindex] => 1
> 22)
> 23)
> 24)
> ...
> ===
> This is output  by c
> function:"socket_recvmsg"(/home/work/php/php/ext/sockets/sendrecvmsg.c:214),

You can find the implementation of socket_recvmsg() in the ext/sockets
directory here:
http://git.php.net/?p=php-src.git;a=blob;f=ext/sockets/sendrecvmsg.c;h=7b9c4e8ad357b73b514dc5feb8dc8d9ca215126b;hb=HEAD#l210



-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Security mailing list

[Kalle Sommer Nielsen]

Hi Christoph

2018-01-10 17:58 GMT+01:00 Christoph M. Becker <cmbecke...@gmx.de>:
> Hi!
>
> Can someone please point out, how I can subscribe to the security
> mailing list?  I have already karma to view security bug reports.

You need to be manually added by one of the ML admins or someone with
karma to the box, usually this has been restricted to RMs, PHP Group
members and a select few. I'm not sure of the policy anymore for
joining this list.


-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] php wiki user, want to contribute edits

[Kalle Sommer Nielsen]

Hi Craig

2018-01-09 16:13 GMT+01:00 Craig Comstock <cr...@unreasonablefarm.org>:
> Hi,
>
> I was upgrading php5 to php7 and managing some C extension code. Noticed a 
> small typo in https://wiki.php.net/phpng-int and wanted to contribute where I 
> could since I'll likely be supporting our use of PHP and extensions for a 
> while.
>
> %s/world/word/
>
> is the very small change I found so far on that page.

Thanks, fixed!


-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Mailing list moderation

[Kalle Sommer Nielsen]

Hi Nikita

2018-01-02 11:49 GMT+01:00 Nikita Popov <nikita@gmail.com>:
> Hi,
>
> This mail is going to both the systems group and internals mailing list.
>
> I would like to request a mailing list suspension for the users
> tonymars...@hotmail.com and li...@rhsoft.net, who have recently been
> aggressively derailing the "Scalar Pseudo-type" thread, despite requests to
> moderate their participation both in that thread, and on a number of
> previous instances -- this is certainly not the first time these two users
> have converted an RFC discussion into a dick measuring contest.
>
> If these users cannot be suspended, I would like to request specific
> instructions under what circumstances users can be suspended from the
> internals list, and what procedures need to be followed to achieve this.

Huge +1, it was a rather annoying thing to begin the new year with,
that these just can't stop even after a few mails by other readers.
I'm cc'ing Rasmus as I can't think of anyone besides Derick that has
karma to make it happen.

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] instanceof survives non-object variables, but crashes on non-object constants.

[Kalle Sommer Nielsen]

Hi

That is fine for code that is broken in the first place. Similarly we added
a warning some years back about array to string conversions.

If your code is like the example, it should be updated and warned about as
you are doing something illogical by first checking the type and or value
of the operand you are passing to instanceof after.

The impact should be minimal as is, so persevering bc for broken usage is a
poor argument imo



On 9 Dec 2017 07.38, "Andreas Hennings" <andr...@dqxtech.net> wrote:

> Adding a warning to something that used to be ok would break existing code.
> I remember a number of cases where I used instanceof on possibly
> non-objects.
>
> if ($x instanceof C) {
>   return $x;
> }
> elseif ($x === NULL) {
>  ...
> }
>
> All such code would then produce warnings.
>
>
> On 9 December 2017 at 07:35, Kalle Sommer Nielsen <ka...@php.net> wrote:
>
>> Hi
>>
>> We should just add a warning to the first example, it seems like an
>> oversight that it was left silent
>>
>> On 9 Dec 2017 07.29 <20%2017%2007%2029>, "Andreas Hennings" <
>> andr...@dqxtech.net> wrote:
>>
>>> The following (https://3v4l.org/A2Tp6) is ok, it simply returns false:
>>>
>>> $x = 1;
>>> $x instanceof \stdClass;
>>>
>>>
>>> The following (https://3v4l.org/IdSBu) gives a fatal error:
>>>
>>> 1 instanceof \stdclass;
>>>
>>> t think this behavior is inconsistent, and we should consider changing
>>> it.
>>>
>>> There are two options, but only one is BC.
>>>
>>> - Let 1 instanceof \stdClass return false, instead of crashing. -> seems
>>> BC
>>> - Let $x instanceof \stdClass crash, if $x is not an object. -> BC break.
>>>
>>> So it seems the first would the option we should take.
>>> This is also what hhvm does, according to https://3v4l.org/IdSBu.
>>>
>>
>

Re: [PHP-DEV] instanceof survives non-object variables, but crashes on non-object constants.

[Kalle Sommer Nielsen]

Hi

We should just add a warning to the first example, it seems like an
oversight that it was left silent

On 9 Dec 2017 07.29, "Andreas Hennings"  wrote:

> The following (https://3v4l.org/A2Tp6) is ok, it simply returns false:
>
> $x = 1;
> $x instanceof \stdClass;
>
>
> The following (https://3v4l.org/IdSBu) gives a fatal error:
>
> 1 instanceof \stdclass;
>
> t think this behavior is inconsistent, and we should consider changing it.
>
> There are two options, but only one is BC.
>
> - Let 1 instanceof \stdClass return false, instead of crashing. -> seems BC
> - Let $x instanceof \stdClass crash, if $x is not an object. -> BC break.
>
> So it seems the first would the option we should take.
> This is also what hhvm does, according to https://3v4l.org/IdSBu.
>

Re: [PHP-DEV] Re: [PHP-CVS] com php-src: ext/sodium: throw exceptions instead of errors: ext/sodium/libsodium.c

[Kalle Sommer Nielsen]

2017-11-29 0:03 GMT+01:00 Nikita Popov <nikita@gmail.com>:
> In summary, the first two commits combined were not a BC break -- they only
> removed a warning and made an error message nicer. After the third commit
> we now *do* have a BC break, because what was previously a SodiumException
> is now an E_ERROR.
>
> I hope we can restore some sanity to this world by reverting that revert...

All in all, E_ERROR should *never* be used by an extension, we should
revert back to using an Exception and re-tag the 7.2.0 release asap


-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: RFC - Array Of for PHP 7

[Kalle Sommer Nielsen]

Hi Tony

2017-10-31 11:35 GMT+01:00 Tony Marston <tonymars...@hotmail.com>:
> This strikes me as being nothing more than a micro-optimisation that does
> nothing but pander to the laziness of certain programmers. Instead of having
> to write a few lines of code to validate something they want the language to
> do it for them. It may come as a surprise to some people, but being a
> programmer actually involves the writing of program code. It is not
> sufficient to express an idea and have the language fill in all the details
> as that forces the language to have to detect and deal with a myriad of
> possibilities.

I do understand where you are coming from, but I don't necessarily
agree on this topic. We can (hopefully) agree that programming
language design is hard, because we need to determine how fine a line
we should have between things thats an integral part of the language,
its standard library or its extensions and how much power the
programmer has in their arsenal to do crazy things.

If we boil things down, then we didn't really need the scalar type
hints, PHP had been working perfectly fine for 20 years without it and
while it does not add anything but a couple of checks at
compile/runtime, its essentially "laziness of certain programmers" it
becomes useful to. Another example is constant visibility modifiers in
PHP 7.1.

I think one of the advocates for features that are within that
category you mention can sometimes be productivity and rid of
boilerplate code. For this case with 'Array Of', I think it makes
perfect sense to add with PHP7's improved type system on that regard,
but thats my personal opinion.

> I would evaluate each proposed change to the language with a simple question
> - does it provide the greatest good to the greatest number? Considering the
> fact that this RFC will only benefit a miniscule minority of developers yet
> make the language more complicated, slower to run, and more difficult to
> maintain as more and more edge cases are identified as "bugs", it offers
> negative benefits to the vast number of programmers who are happy with the
> language as it currently exists. As such it fails that test and should be
> rejected.

Tho you said its a micro optimization, would argue that (see [1]), it
far from makes the code complicated, internally it doesn't add any
complexity and only adds a member to the arg_info, which is an
unsigned char, it wouldn't do anything unless a type is specified
anyway and the slower to run argument above is pretty void, sure it
adds a few CPU instructions but its not something you will feel unless
you are Facebook, in which case you already re-implemented the
language on your own.

I fail to see how it offers "negative benefits to the vast number of
programmers who are happy with the language as it currently exists", I
myself don't like PDO, so I just use mysqli instead, great. If its not
something that affects the programmer and the programmers code
continue to run, I fail to see how it negatively impacts the vast
majority. If I asked you how you feel about the exif extension now
supports streams as arguments instead of only file names, would you
care much unless you are actively using the exif extension? Probably
not.


[1] https://gist.github.com/KalleZ/c7ba4f78314c989e27710e4fa14e2f3e



-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Consistent indentation for test files

[Kalle Sommer Nielsen]

2017-10-29 22:30 GMT+01:00 Anatol Belski <a...@php.net>:
> Whichever way would be chosen, implementing a pre commit hook would make 
> sense to be done. To mention, tabs were easier for me, too, but not a big 
> deal anyway.

I'm on the same boat as Anatol here, whatever is choosen is fine with
me, tho I generally tend to use tabs unless the test I copy/pasted had
spaces, I would follow that.



-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Callout for bug tracker cleanup

[Kalle Sommer Nielsen]

Dear Internals

I have in the past few days been working on, and I continue to work on
cleaning up our bug tracker. We are close to 5000 open bugs[1], while
about 1500 of those are FR requests, some opened as far back as
2001[2].

I would urge more to help bring down that number, even if you just got
5 minutes to take a look at a random open bug[3] and classify it, it
would be a lot of help. A lot of the old ones are report still from a
PHP4 era, which may no longer be relevant or even fixed/implemented in
a newer version.

Another notable thing is that a lot of bugs are assigned but are often
forgotten, I would argue that it does two negative things which we
should be attempting to avoid:

 - Creating a false feeling that a report is actively been worked on
and the reporter expects this to be fixed in a reasonable future.
 - It may steer away new contributors who wants to fix a bug but the
ones they are interested in are already "falsely" assigned as to the
point above.

I would like for those who have assigned bugs to them[4] to review
their assigned bugs and unassign them if you don't intend on working
on them in a not too distant future to open them up for others to
grab.

Currently I'm going over every single report to try classify them,
close reports which would require an RFC, PECL packages with no
releases for literally years and unassign people from bug reports
which have not been active (committed) in a long time, or similar. I
don't want to step on anyones toes but I think it is time that there
is done something about this, if you are unhappy with a change I have
done to a report where you were assigned, then please reach out  as
I'm doing this in the best intend for PHP.



[1] 
https://bugs.php.net/search.php?cmd=display_by=assign=DESC=8=Open_by=id
[2] https://bugs.php.net/bug.php?id=12802
[3] https://bugs.php.net/random
[4] https://bugs.php.net/search.php?cmd=display=USERNAME

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re:[PHP-DEV] [VOTE] Allow a trailing comma in function calls

[Kalle Sommer Nielsen]

Hi CHU Zhaowei

2017-10-22 7:24 GMT+02:00 CHU Zhaowei <m...@jhdxr.com>:
> Hello Sammy,
>
>
> I'd like to know if a trailing comma would affect the number of args or not. 
> for example,
> ```
> function foo(){
>   return func_num_args();
>
> }
> foo('a','b',);
> ```
> would return 2 or 3?

With the current patch submitted for this RFC, your example will
return 2, as it will simply ignore the trailing comma at the end of
your call. You can see the more detailed test at github here[1].


[1] 
https://github.com/SammyK/php-src/compare/master...rfc-trailing-comma-function-calls#diff-88d4f8d1ae810e0722bf59cf1a739228

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Expose gmp_ce and friends

[Kalle Sommer Nielsen]

Hi Sara

2017-10-02 23:33 GMT+02:00 Sara Golemon <poll...@php.net>:
> Stas specifically, but also others:
>
> Any objections if I apply
> https://github.com/php/php-src/compare/master...sgolemon:gmp.export to
> make consuming GMP objects from third-party extensions easier?

+1, only note I have is that with the change to config.m4, a relevant
one should maybe also follow for phpize on Windows for config.w32


-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] GD vs Imagick

[Kalle Sommer Nielsen]

2017-08-15 12:52 GMT+02:00 Rasmus Schultz <ras...@mindplay.dk
> Why is the less-capable image library the default on the PHP platform? Why
> not Imagick?

Most likely because no one have come fourth and attempted to push it
into core and have been willing to do all the work required for it.

As for GD, I would argue and say that for the average developer
needing image functionality, it fits the needs, the API is clunky yes
and I have been wanting to redesign at least the PHP binding for quite
some time, but that is a huge task, for a marginally small gain imo.

If you are willing to do the work, and work together with the
maintainer of Imagick, then I don't see any showstoppers for why it
can't be included in the php-src through an RFC much like Sodium
recently was added to 7.2


-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] WDDX serialization and security

[Kalle Sommer Nielsen]

On 11 Aug 2017 15.38, "Remi Collet"  wrote:

Le 11/08/2017 à 15:15, Nikita Popov a écrit :

> I'm wondering if it might be time to remove (i.e. deprecate and move to
> PECL) the wddx extension?

+1



+2

Re: [PHP-DEV] Size of release tarballs

[Kalle Sommer Nielsen]

2017-07-30 21:41 GMT+02:00 Sara Golemon <poll...@php.net>:
> On Sun, Jul 30, 2017 at 9:22 AM, Anatol Belski <a...@php.net> wrote:
>>> I think we can handle it in the old-fashioned way now - just notify the RMs 
>>> and
>>> clean up the repos.
>>>
>>
> Some scripts for RMs to run periodically will get us 80% of the way
> there, yeah.  I don't mind tossing some together and updating
> README.RELEASE-PROCESS to reflect that duty.  In fact, I think it
> might be worth breaking out this file into README.RELEASE-MANAGEMENT
> to cover non-release parts of the RM role (such as keeping an eye on
> out-sized files and that people observe merging process, etc...)

I committed some changes which should reduce the exif tests by a
larger margin in a7484beea2711c28f548d4c4e7cc10c5271b7890, I think
this will help make the tarballs return back to normal


-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Changes to SuperGlobals for PHP 8 (was: something about session_start...)

[Kalle Sommer Nielsen]

Hi

2017-07-29 22:17 GMT+02:00 Stanislav Malyshev <smalys...@gmail.com>:
> I've seen scenarios where it is very useful. Sure, you can always build
> another layer of indirection and solve it this way, but it's just making
> people do more work for no reason. I don't see any problem that would solve.

Sure it seems useful, but I see it more as a hack if you are just
writing to superglobals anyway, if you need to change something you
should do that with your own logic instead.

If its something simple such as your code assumes $_GET['id'] always
is available, then either write it to a temp variable.

I know many applications nowadays are not written with an excess
amount of globals everywhere, but writing to a global without
explicitly declaring you want to, can cause some hard to debug cases
if one function modifies a global and another assumes an unmodified
value. I'd like to see that gone.


-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Changes to SuperGlobals for PHP 8 (was: something about session_start...)

[Kalle Sommer Nielsen]

2017-07-28 17:11 GMT+02:00 Sara Golemon <poll...@php.net>:
> I'm sure there will be many strong opinions on this, but let's move
> this to a new thread. :D
>
> 1. This would be an 8.0 change as it does represent a significant BC change.
> 2. We can discuss the possibility of INI options or other mitigation
> strategies for misbehaving code bases (and they do exist).
> 3. I'm definitely not decided on what I'd like from default session
> behavior. An error isn't out of the question, for sure.

I for one thing it makes a lot of sense to make superglobals
read-only, writing to them seems more like a hack anyway and should be
avoided


-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Remove ODBCRouter support

[Kalle Sommer Nielsen]

Hi

If no one objects, I intend to remove the old ODBCRouter support from
ext/odbc, this has not had any releases for 8 years on Unix and I
highly doubt anyone are still using that with PHP. I will commit a
patch within the next few days for this.

I had a look over all other Unix flavors we support with ODBC, and all
of them had releases within the last few years so I consider them
still supported.


-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] bugs.php.net website

[Kalle Sommer Nielsen]

Hi Johannes

2017-07-24 20:10 GMT+02:00 Johannes Schlüter <johan...@schlueters.de>:
> With this very specific item we need to make sure the server actually
> has pdo_mysql enabled. I currently have no access and assume it does.

The bug tracker provides an "admin" interface which have a phpinfo()
page[1], and yes bugs.php.net does have pdo_mysql


[1] https://bugs.php.net/admin/?action=phpinfo

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] bugs.php.net website

[Kalle Sommer Nielsen]

Hi Niklas

2017-07-24 11:51 GMT+02:00 Niklas Keller <m...@kelunik.com>:
> It's unmaintained code, nobody wants to touch it. Any attempt to improve
> anything doesn't go anywhere, because there are too many people saying the
> current state is fine.

I doubt the fact that because its written this way is making no one
wants to touch the code, sure it plays a factor but not that big one.
I don't mind improving it at all, what I do mind is that we should
include tons of additional code for no real gain other than syntax
looking better for the reader.

> See https://github.com/php/web-bugs/pull/26 for an example.

Maciej got web karma and can commit this, I don't really mind this one
as an example, tho since we use mysqli, we should simply just use the
native mysqli class, and then we don't run into the issue as described
with PDO having no numRows method. I even would go as far as saying we
should get rid of the PEAR dependency in bugsweb, we even had issues
with pear releases that php-src depends on when 7.0.0 was about to be
released.


> There's no need for a framework, libraries are just fine. But saying that
> the PHP project is a good example for how powerful the language is, is ...
> really strange.

I don't think it is that strange, again a subjective statement. I can
agree that in the current state its not that much an example, but I
think that should be the goal for all php.net web projects.

> The attitude of "don't change anything, it's fine" makes it really hard to
> find motivation to contribute anything.

I'm not saying don't change its fine, what I'm saying is that we
shouldn't change the overall arching of the website to be bloated.


-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] bugs.php.net website

[Kalle Sommer Nielsen]

Hi Johannes

2017-07-24 0:03 GMT+02:00 Johannes Schlüter <johan...@schlueters.de>
> It is also good for the PHP ecosystem at large to show we're using
> libraries, where it makes sense. If we use a variety we're also not
> favoring single ones :)

As much as I agree with that, I do not see a big thing that using a
library makes it much easier to do for a bug tracker that fits our
needs. Okay maybe a captcha or SSO, but the rest can be done in a
simple encapsulation that we don't need thousands of lines of code
just to implement something so basic.

> A reason for this is that these sites are not "actively developed" and
> it should be possible to find the relevant code within a few minutes,
> even when looking at it every second year or though. With the current
> architecture I go to search.php's code and can see what's going on.
> With a framework I have to see how the framework handles the routing
> and where the relevant controller is and so on and so forth ...  this
> is contrary to other projects under constant development possibly by
> larger teams and is also different from developing a generic bug
> tracker (or whatever site you look at) where things need to be
> configurable for different usage scenarios ...

I think the main reason for these sites not being actively developed
is that they do their job, I did some minor cosmetics to the bug
tracker, but besides maybe better integration with github PR's, I
can't see that many more features our tracker needs.

I get that with a framework it makes the debugging route easier or if
you are just curious to study the code, and we can still achieve that
with simplistic encapsulation where it makes sense. If we keep your
example with search, what we can do is to implement functionality that
returns records based on criteria, we need that functionality in
multiple places anyway.

I always saw the PHP project as an example to how powerful the
language is by its own, out of the box and I will continue to advocate
for us to continue that way

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 7.2 forked

[Kalle Sommer Nielsen]

2017-07-22 18:48 GMT+02:00 Nikita Popov <nikita@gmail.com>:
> What's out current state regarding ABI? I've recently done some work on
> making mbstring slightly less abysmally slow, but landed the changes on
> master only, because this included ABI breaks in mbfl/mbstring APIs and
> globals. Is this something I can land in PHP-7.2, or is it closed to
> extension ABI changes?

afair ABI can be broken until a branch/release hits RC, after that its
on case by case basis



-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] php.net website

[Kalle Sommer Nielsen]

Hi Mathias

2017-07-19 19:07 GMT+02:00 Mathias Grimm <mathiasgr...@gmail.com>:
> I was briefly asking Sara about it and as she pointed out it is likely a
> big project but I think we can do something about it.

A side note to all of this, I would personally like to see if parts of
php.net redone, that we can integrate windows.php.net back into the
main website, I was never a big fan of the separation of the two. The
binaries are hosted by Microsoft if I remember correctly and has its
own mirroring system, we could still keep this by just pointing the
downloads to the relevant links to windows.php.net mirroring, as I can
easily agree with the size amount that the Windows binaries do contain
with all these flavors we produce nowadays.



-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] bugs.php.net website

[Kalle Sommer Nielsen]

is odd and special gentlemans club, but most of these
points and procedures has been what we always have done, it is not
that I don't see a reason to change things around now, but that is
another and larger discussion that the project as a whole should
decide if needs changing or not.

I hope you aren't disencouraged but all of this, and even though it is
very different from the background you come from and in the end you
just want to contribute, you will still continue to push a new bug
tracker though. I wouldn't mind joining in on this as a now senior
contributor for PHP.


-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] INSTALL and win32/install.txt files

[Kalle Sommer Nielsen]

Hi Sara

2017-07-19 15:34 GMT+02:00 Sara Golemon <poll...@php.net>:
> There's some (admittedly limited) benefit to having such instructions
> in tree.  Is there any way this can be auto-generated from docbook
> sources?  We could easily add it to the release process.

I think it would be fairly easy, for me personally its been too long
since I worked with PhD to make a renderer to generate just that

> Though I'm not super-bothered personally if you want to just make it a
> link.  The idea of installing internet software without an internet
> connection is a bit weird.

I totally agree, it is a bit weird for those cases without internet
access, but I think we can assume that 99.9% of everyone using PHP has
access to the internet one way or another. If I remember correctly
then back some almost 10 years ago we had a similar talk but it was
the same concern that not everyone had internet access and it would
generally be a "nice thing" to have, I do agree with the latter of
that statement.

> That's fixable, though should be addressed on an individual basis.  We
> have "doc" people who have @php.net accounts and have never pushed a
> diff in their lives.  I'm sure someone with AVAIL karma can see to
> their needs if they request php-src/doc karma.

True, but barely anyone cared to do anything about it, and tho I don't
think the karma is the problem. The only people that updates them is
the ones that grep and find a hit. Having to maintain the same
resource in 3 places is odd too, INSTALL, win32/install.txt,
phpdoc/en/install/?

TL;DR if no one really objects, I will turn these into links over the
course of the weekend


-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] INSTALL and win32/install.txt files

[Kalle Sommer Nielsen]

Howdy

I did a recent commit with some internal cleanup and I noticed both of
these files are largely outdated, is there any objects of replacing
their contents with a link to our docs at php.net instead?

Side note, far from all doc people have karma for these two files, and
they are largely uncharged from the days of PHP4.

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php