Re: [PHP-DEV] json(Raw)Serializable?

2017-10-23 Thread Stanislav Malyshev 
Hi!

> It's not terribly unreasonable IMO, but before I just writeup the RFC
> as described (jsonRawSerialize taking preceedence over jsonSerialize),
> I thought I'd ask for opinions on the specifics.
> 
> In psuedo-code:
> 
> if (is_object($obj)) {
>   if ($obj implements JsonRawSerializable) {
> // use $obj->jsonRawSerialize() as is.
>   } elseif ($obj implements JsonSerializble) {
> // use json_encode($obj->jsonSerialize())
>   } else {
> // Serialize the object's public properties as a key/value map
>   }
> }

I'm not sure I feel very comfortable with having specialized serialize
interfaces for every format, yet more with having more than one of them.

There's also validation problem - if we don't ensure this is valid JSON,
then whole serialization setup is broken, and who knows which
consequences this will bring.

Also, I'm not sure what is the case for fixed JSON serialization - cases
where the data is completely static and yet you still need to serialize
it is pretty rare IMHO. Yes, we save some cycles on serializing such
things, but how often that happens, really? If it's static, why not just
set it on loading? Maybe I miss some reasonable use case, but so far
sounds pretty exotic to me.


-- 
Stas Malyshev
smalys...@gmail.com

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

[PHP-DEV] Callout for bug tracker cleanup

2017-10-23 Thread 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&order_by=assign&direction=DESC&limit=8&status=Open&reorder_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&assign=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] [RFC] Flexible Heredoc and Nowdoc Syntaxes

2017-10-23 Thread Christopher Jones 



On 13/10/17 8:40 pm, Thomas Punt wrote:

Morning internals,


I'd like to propose an RFC to make the heredoc and nowdoc syntaxes more 
flexible[1]. Any thoughts?


Thanks,

Tom


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



I like the added flexibility in placement of the end token, but I think requiring only tabs or spaces, and stripping whitespace from all {here|now}doc 
lines is error prone and adds unnecessary complexity.


Chris

--
http://twitter.com/ghrd


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

[PHP-DEV] json(Raw)Serializable?

2017-10-23 Thread Sara Golemon 
https://bugs.php.net/bug.php?id=75400 is asking for a version of
JsonSerializable which doesn't involve deserializing/reserialzing
round trips when a chunk of JSON is known in advance.

It's not terribly unreasonable IMO, but before I just writeup the RFC
as described (jsonRawSerialize taking preceedence over jsonSerialize),
I thought I'd ask for opinions on the specifics.

In psuedo-code:

if (is_object($obj)) {
  if ($obj implements JsonRawSerializable) {
// use $obj->jsonRawSerialize() as is.
  } elseif ($obj implements JsonSerializble) {
// use json_encode($obj->jsonSerialize())
  } else {
// Serialize the object's public properties as a key/value map
  }
}

Perhaps with the stipulation that if jsonRawSerialize() returns null,
we'd fallback on jsonSerialize().  Any other non-string results in an
encoding error.

-Sara

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

RE: [PHP-DEV] [RFC] PCRE2 migration

2017-10-23 Thread Anatol Belski 
Hi Jakub,

> -Original Message-
> From: jakub@gmail.com [mailto:jakub@gmail.com] On Behalf Of Jakub
> Zelenka
> Sent: Monday, October 23, 2017 10:43 PM
> To: Anatol Belski 
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] [RFC] PCRE2 migration
> 
> Hey
> 
> 
> On Mon, Oct 16, 2017 at 9:17 AM, Anatol Belski   > wrote:
> 
> 
>   Hi,
> 
>   I would like hereby to put the RFC about the PCRE2 migration for the
>   core https://wiki.php.net/rfc/pcre2-migration
>   under discussion. A basic
>   port is available here https://github.com/php/php-src/pull/2857
>   for a
>   review.
> 
> 
> 
> 
> Sorry if that's a stupid question and I'm missing something important but why 
> do
> we need to still bundle PCRE2?
> 
I ask such questions just for the fun of it all the time, that makes sense to 
my character 😊

The point of the RFC is the max BC. Currently PCRE is bundled. Otherwise, the 
lib is essential for the core and thus needs to be always available. For older 
distro versions like for example Debian Jessie or other OSes not yet providing 
PCRE2 from the package management, that would be the only way to get a newer 
PHP version, even if compiled by hand. Except maybe when libpcre2 were provided 
by a third party repo, or a PPA in the Debian terminology.

Another point on that is, even if a package is available on the target platform 
- the bundled version is what is tested and highly recommended. Builders can 
decide otherwise, but what we provide makes the point. Lately, for example - 
the valgrind support is also essential, as a release version supplied by a 
distro likely wouldn't be built with valgrind support but it's required to 
debug PHP issues.

Otherwise, there's no need for bundling. This dependency is currently not 
patched in the way it would be the only one to be required bundled. It is 
simply handy to have it bundled for the development and compatibility. Any 
distribution can decide, whether they would use it bundled or external.

Regards

Anatol

Re: [PHP-DEV] [RFC] PCRE2 migration

2017-10-23 Thread Jakub Zelenka 
Hey

On Mon, Oct 16, 2017 at 9:17 AM, Anatol Belski  wrote:

> Hi,
>
> I would like hereby to put the RFC about the PCRE2 migration for the
> core https://wiki.php.net/rfc/pcre2-migration under discussion. A basic
> port is available here https://github.com/php/php-src/pull/2857 for a
> review.
>
>
Sorry if that's a stupid question and I'm missing something important but
why do we need to still bundle PCRE2?

Cheers

Jakub

[PHP-DEV] RE: [RFC] PCRE2 migration

2017-10-23 Thread Anatol Belski 
Hi Christoph,

> -Original Message-
> From: Christoph M. Becker [mailto:cmbecke...@gmx.de]
> Sent: Monday, October 23, 2017 4:24 PM
> To: Anatol Belski ; internals@lists.php.net
> Subject: Re: [RFC] PCRE2 migration
> 
> In my opinion, the only real issue is that the internal API would change (the 
> few
> userland affecting changes appear to be acceptable).  I can't assess how many
> extensions actually use the public API of ext/pcre, but this might be an issue
> regarding the adoption of PHP 7.3.
> 
Some exts use PCRE or the PHP API, of course. From what I've seen so far

- The migration is easy, despite the PCRE2 API is somewhat different. If asked, 
I could help patching any code for PCRE2 support.
- there's time to rework the API as in the patch, some points can be changed 
significantly
- From what I could tell, the ratio of PECL exts using PCRE is low. In fact, I 
can't remember any, OFC there are be some.

> This said, I'm presently +0.9 on accepting the RFC.
> 
PCRE2 implements new features and fixes issues, while the legacy version only 
gets backports which are not optimal. At the time after two years PCRE2 release 
and the situation with PCRE support, switching seems a thing to me. The 
existing features are not broken, better Unicode support and improvements in 
functionality and memory handling speak for that.  

Regards

Anatol

[PHP-DEV] Re: [RFC] PCRE2 migration

2017-10-23 Thread Christoph M. Becker 
On 16.10.2017 at 10:17, Anatol Belski wrote:

> I would like hereby to put the RFC about the PCRE2 migration for the 
> core https://wiki.php.net/rfc/pcre2-migration under discussion. A basic 
> port is available here https://github.com/php/php-src/pull/2857 for a 
> review.

Thanks, Anatol, for working on a PCRE2 compatible ext/pcre!

In my opinion, the only real issue is that the internal API would change
(the few userland affecting changes appear to be acceptable).  I can't
assess how many extensions actually use the public API of ext/pcre, but
this might be an issue regarding the adoption of PHP 7.3.

This said, I'm presently +0.9 on accepting the RFC.

-- 
Christoph M. Becker

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