Re: [PHP-DEV] Re: [RFC] LDAP EXOP

[Andreas Heigl]

Hey Andreas.

Am 04.07.17 um 00:16 schrieb Andreas Treichel:
> Hey Côme, hey Andreas.
> 
>> string|FALSE ldap_exop_whoami(resource $link) - The returned string is
>> the DN of the currently bound user.
> 
> In my opinion the code is really ease to read with exceptions.
> 
> try {
> $user = ldap_exop_whoami($link);
> }
> catch(Throwable $e) {
> }

It definitely is easier to read. But let's not try too much in one go.
As all of the current extension uses errors I'd currently stick to the
errors and leave moving to extensions for a later change. Partly to keep
at least some kind of consistency and partly to not come into the trap
of moving to extensions completely and therefore breaking BC…
> 
>> string|FALSE ldap_exop_passwd(resource $link [, string $user [, string
>> $oldPassword [, string $newPassword]]] - The returned string is the new
>> password of the user. Either the given newPassword or a newly
>> generated one.
> 
> Change password of current user with a random password.
> ldap_exop_passwd($link);
> 
> Change password of $user with a random password.
> ldap_exop_passwd($link, $user);
> 
> Change $oldPassword of $user with a random password.
> ldap_exop_passwd($link, $user, $oldPassword);
> 
> Change $oldPassword of $user to $newPassword.
> ldap_exop_passwd($link, $user, $oldPassword, $newPassword);
> 
> As i wrote the four samples, i actually already like the ordering of the
> arguments as it seems to make sense.
> 
> 
> How is the behavior of the following?
> 
> Change $oldPassword of current user to $newPassword?
> ldap_exop_passwd($link, '', $oldPassword, $newPassword)
ldap_exop_passwd($link, null, $oldPassword, $newPassword);

Though passing an empty string should work also with the current code.
But I'd prefer to pass NULL
> 
> Change $oldPassword of $user to empty string? Or random? Or is this an
> error?
> ldap_exop_passwd($link, $user, $oldPassword, '');

IMHO you can't change to an empty string. Because that would be like not
setting a password at all. I'd restrict that so far that providing an
empty password will cause the server to generate a random password that
is then returned.
> 
> 
> My previous suggestion was to split the function into two versions to
> reduce the amount of arguments.
> 
> string|FALSE ldap_exop_passwd(resource $link, string $user, string
> $newPassword [, string $oldPassword])
> 
> string|FALSE ldap_exop_random_passwd(resource $link, string $user [,
> string $oldPassword])

I would not do that as it bloats the API in an - in my eyes -
unnecessary way. Let's stick to one function for changing password…

One thing though that I thought about: Chapter 4 of RFC 3062 explicitly
states that this function should only be available with confidentially
support like TLS. So perhaps we should check whether the data will be
transfered via a secure connection and - if not - raise an error?

Cheers

Andreas

-- 
  ,,,
 (o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl   |
| mailto:andr...@heigl.org  N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org   http://hei.gl/wiFKy7 |
+-+
| http://hei.gl/root-ca   |
+-+



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] 7.2 behavior break, Bug #74836 isset on zero-prefixed numeric indexes in array broken

[Dmitry Stogov]

Hi,


I agree with Stas and Sara.

it's easier to revert the last optimization and return to 7.1 behavior (even if 
it's inconsistent).

Fixing this inconsistency in PHP-Next would require RFC.


Thanks. Dmitry.





From: Stanislav Malyshev 
Sent: Tuesday, July 4, 2017 3:23:27 AM
To: Dmitry Stogov; nikita@gmail.com; Sara Golemon; Bob Weinand
Cc: PHP internals list
Subject: Re: [PHP-DEV] 7.2 behavior break, Bug #74836 isset on zero-prefixed 
numeric indexes in array broken

Hi!

>
> Please take a look at https://bugs.php.net/bug.php?id=74836
>
> What is the best option to fix this?
>
>
> The most consistent way, from my point of view - disabling zero-prefexed 
> numeric strings in all cases, but this is a new behavior break.

I think this is very corner case, for string offsets. So for 7.2 to drop
support for leading-0 string, with note in UPGRADING and maybe a
notice/warning, would be ok. It is not good though that read access and
isset are not consistent, this should always work the same. It is
especially worrying that "010" and $i = "010" work differently, that
should never happen.

The problem is if we disable it for string offsets, it would be weird to
keep it for array offsets, and so for arrays "010" should be treated as
string I guess? Which may involve more breakage. So I wonder if a better
way would be to just let it be as it always was, and maybe make
leading-0 strings not to be interpreted as numbers for both cases in
PHP.next when we can do BC breaks.

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

Re: [PHP-DEV] 7.2 behavior break, Bug #74836 isset on zero-prefixed numeric indexes in array broken

[Stanislav Malyshev]

Hi!

> 
> Please take a look at https://bugs.php.net/bug.php?id=74836
> 
> What is the best option to fix this?
> 
> 
> The most consistent way, from my point of view - disabling zero-prefexed 
> numeric strings in all cases, but this is a new behavior break.

I think this is very corner case, for string offsets. So for 7.2 to drop
support for leading-0 string, with note in UPGRADING and maybe a
notice/warning, would be ok. It is not good though that read access and
isset are not consistent, this should always work the same. It is
especially worrying that "010" and $i = "010" work differently, that
should never happen.

The problem is if we disable it for string offsets, it would be weird to
keep it for array offsets, and so for arrays "010" should be treated as
string I guess? Which may involve more breakage. So I wonder if a better
way would be to just let it be as it always was, and maybe make
leading-0 strings not to be interpreted as numbers for both cases in
PHP.next when we can do BC breaks.

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

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

[PHP-DEV] /usr/bin/ld: cannot find -lmysqlclient | error: wrong mysql library version or lib not found

[Guillermo Cespedes]

Hi,

I am compiling MariaDB 10.2.6 and PHP 7.1.6

I'm trying it on Debian 8.8 32x / x64 on DigitalOcean

See the script:
https://gist.github.com/dertin/8de14e458dd4f0d3acb5f0deff120951 


But I have problems compiling PHP with MariaDB

# grep 'mysql’ config.log

$ ./configure --prefix=/usr/local/php7 --enable-huge-code-pages 
--with-config-file-scan-dir=/usr/local/php7/etc/conf.d --without-pear 
--enable-bcmath --with-bz2 --enable-calendar --enable-intl --enable-exif 
--enable-dba --enable-ftp --with-gettext --with-gd --with-jpeg-dir 
--enable-mbstring --with-mcrypt --with-mhash --enable-mysqlnd 
--with-mysql-sock=/var/run/mysqld/mysqld.sock 
--with-mysqli=/usr/local/mysql/bin/mariadb_config 
--with-pdo-mysql=/usr/local/mysql --with-openssl --enable-pcntl --with-pspell 
--enable-shmop --enable-soap --enable-sockets --enable-sysvmsg --enable-sysvsem 
--enable-sysvshm --enable-wddx --with-zlib --enable-zip --with-readline 
--with-curl --enable-simplexml --enable-xmlreader --enable-xmlwriter 
--enable-fpm --with-fpm-user=www-data --with-fpm-group=www-data



configure:52615: result: /var/run/mysqld/mysqld.sock

configure:52749: checking for mysql_set_server_option in -lmysqlclient

configure:52774: cc -o conftest -I/usr/include -g -O2 -fvisibility=hidden  
-Wl,-rpath,/usr/local/mysql/lib/ -L/usr/local/mysql/lib/ -L/usr/lib  
-Wl,-rpath,/usr/local/lib -L/usr/local/lib -Wl,-rpath,/usr/lib/x86_64-linux-gnu 
-L/usr/lib/x86_64-linux-gnu -lmariadb -ldl -lm -lssl -lcrypto conftest.c 
-lmysqlclient  -lmcrypt -lltdl -lstdc++ -lpng -lz -ljpeg -lcurl -lbz2 -lz -lrt 
-lm -ldl -lnsl  -lxml2 -lz -lm -ldl -lssl -lcrypto -lcurl -lxml2 -lz -lm -ldl 
-lssl -lcrypto -licui18n -licuuc -licudata -licuio >&5
/usr/bin/ld: cannot find -lmysqlclient
| char mysql_set_server_option ();
| return mysql_set_server_option ();

configure:53081: error: wrong mysql library version or lib not found. Check 
config.log for more information.
ac_cv_lib_mysqlclient___mysql_set_server_option=no

:-/

Re: [PHP-DEV] Re: [RFC] LDAP EXOP

[Andreas Treichel]

Hey Côme, hey Andreas.

> string|FALSE ldap_exop_whoami(resource $link) - The returned string is
> the DN of the currently bound user.

In my opinion the code is really ease to read with exceptions.

try {
$user = ldap_exop_whoami($link);
}
catch(Throwable $e) {
}


string|FALSE ldap_exop_passwd(resource $link [, string $user [, string
$oldPassword [, string $newPassword]]] - The returned string is the new
password of the user. Either the given newPassword or a newly generated one.


Change password of current user with a random password.
ldap_exop_passwd($link);

Change password of $user with a random password.
ldap_exop_passwd($link, $user);

Change $oldPassword of $user with a random password.
ldap_exop_passwd($link, $user, $oldPassword);

Change $oldPassword of $user to $newPassword.
ldap_exop_passwd($link, $user, $oldPassword, $newPassword);

As i wrote the four samples, i actually already like the ordering of the 
arguments as it seems to make sense.



How is the behavior of the following?

Change $oldPassword of current user to $newPassword?
ldap_exop_passwd($link, '', $oldPassword, $newPassword);

Change $oldPassword of $user to empty string? Or random? Or is this an 
error?

ldap_exop_passwd($link, $user, $oldPassword, '');


My previous suggestion was to split the function into two versions to 
reduce the amount of arguments.


string|FALSE ldap_exop_passwd(resource $link, string $user, string
$newPassword [, string $oldPassword])

string|FALSE ldap_exop_random_passwd(resource $link, string $user [, 
string $oldPassword])




Or is that complete and utter nonsense?


Maybe, so lets talk about the functions. i dont like the unnecessary 
references. But if the references makes more sense in this situation, 
please use them.



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

[PHP-DEV] GOOD Benchmark Results for PHP Master 2017-07-02

[lp_benchmark_robot]

Results for project PHP master, build date 2017-07-02 19:23:14-07:00
commit: f066f59
previous commit:cf7ae70
revision date:  2017-07-02 10:41:38-04:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, 
stepping 2, LLC 45 MB
mem:128 GB
os: CentOS 7.1
kernel: Linux 3.10.0-229.4.2.el7.x86_64

Baseline results were generated using release php-7.0.0, with hash 60fffd2 from
2015-12-01 04:16:47+00:00

---
benchmark   relative   change since   change since  
current rev run
std_dev*   last run   baseline  
   with PGO
---
:-|   Wordpress 4.2.2 cgi -T1  0.20%  0.79%  3.57%  
  8.07%
:-|   Drupal 7.36 cgi -T1  0.19%  0.27%  1.93%  
  5.45%
:-|   MediaWiki 1.23.9 cgi -T5000  0.08%  0.34%  3.46%  
  3.98%
:-)   bench.php cgi -T100  0.02%  1.48% 46.68%  
  3.47%
:-)  micro_bench.php cgi -T10  0.01%  2.48% 22.35%  
  2.75%
:-)  mandelbrot.php cgi -T100  0.01%  2.18% 44.51%  
 -2.54%
---

* Relative Standard Deviation (Standard Deviation/Average)

If this is not displayed properly please visit our results page here: 
http://languagesperformance.intel.com/good-benchmark-results-for-php-master-2017-07-02/

Note: Benchmark results for Wordpress, Drupal, MediaWiki are measured in
fetches/second while all others are measured in seconds.
More details on measurements methodology at: 
https://01.org/lp/documentation/php-environment-setup.

Subject Label Legend:
Attributes are determined based on the performance evolution of the workloads
compared to the previous measurement iteration.
NEUTRAL: performance did not change by more than 1% for any workload
GOOD: performance improved by more than 1% for at least one workload and there
is no regression greater than 1%
BAD: performance dropped by more than 1% for at least one workload and there is
no improvement greater than 1%
UGLY: performance improved by more than 1% for at least one workload and also
dropped by more than 1% for at least one workload


Our lab does a nightly source pull and build of the PHP project and measures
performance changes against the previous stable version and the previous nightly
measurement. This is provided as a service to the community so that quality
issues with current hardware can be identified quickly.

Intel technologies' features and benefits depend on system configuration and may
require enabled hardware, software or service activation. Performance varies
depending on system configuration.


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

Re: [PHP-DEV] Re: [RFC] LDAP EXOP

[Andreas Heigl]

Hey Côme, hey Andreas.

Am 03.07.17 um 17:04 schrieb Andreas Treichel:
> Hello,
> 
> please change the signature form
> 
> bool ldap_exop_whoami(resource $link, string &$result)
> 
> to
> 
> string ldap_whoami(resource $link);
> 
> i dont see the benefit to return a single value with a reference.
> 
> Without a reference the function can used as an argument:
> doSomethingWithTheUserName(ldap_whoami($link));
> 
> 
> With a reference a variable is required:
> ldap_whoami($link, $username);
> doSomethingWithTheUserName($username);
> 
> 
> same with the return statement of a method:
> 
> class MyLdap
> {
> public function getCurrentUser(): string
> {
> return ldap_whoami($this->link);
> }
> }
> 
> class MyLdap
> {
> function getCurrentUser(): string
> {
> ldap_whoami($this->link, $username);
> return $username;
> }
> }

After thinking a while about this I think it would be a good idea to
alter the signature of the functions and return a value or FALSE instead
of a boolean value.

In my eyes the code and the extension would benefit in a few ways:

* It would allow us to slowly get rid of pass-by-reference variables
* It would make it easier for users to get a value
* It would allow us to shift to use Exceptions instead of errors more easily

For methods that could return more than one value we could return an
array or an object.

There are currently both ways in the code but from the discussions I've
had so far I've learned that removing the references (and getting rid of
the resources) would be a plus.

From what I've seen in the code at least removing the pass-by-reference
should be possible without too much changes.

So the signatures would look like this:

string|FALSE ldap_exop_whoami(resource $link) - The returned string is
the DN of the currently bound user.

string|FALSE ldap_exop_passwd(resource $link [, string $user [, string
$oldPassword [, string $newPassword]]] - The returned string is the new
password of the user. Either the given newPassword or a newly generated one.

Both would return FALSE on an error (or throw an Exception) so one can
use them like this

if (false === ($password = ldap_exop_passwd($link))) {
// something went wrong
} else {
echo $password;
}

Or is that complete and utter nonsense?



Cheers

Andreas

-- 
  ,,,
 (o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl   |
| mailto:andr...@heigl.org  N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org   http://hei.gl/wiFKy7 |
+-+
| http://hei.gl/root-ca   |
+-+



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates

[Niklas Keller]

2017-07-03 19:24 GMT+02:00 Sara Golemon :

> On Mon, Jul 3, 2017 at 1:12 PM, Niklas Keller  wrote:
> > Additionally there will be two INI options
> > which are only added to PHP 7.1 and 7.0 to allow people to immediately
> > upgrade to secure defaults without any risk of breaking other apps.
> >
> I understand what you're going for there, but it's just a bit weird to
> have that INI option exist for a weird pair of version ranges and not
> forward.   I'd say keep the INI in 7.2 and (perhaps) mark them
> deprecated.  There's no sense making that upgrade path unreasonably
> difficult.
>

True, but I'd like it to be an INI option to strengthen the security, but
not allow to weaken it. You really shouldn't use MD5 or SHA1 for TLS
certificates 2018 (!). If you really need it there, you can still set a
default stream context option, but we won't clutter the INI options of
future versions.

Regards, Niklas

Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates

[Sara Golemon]

On Mon, Jul 3, 2017 at 1:12 PM, Niklas Keller  wrote:
> Additionally there will be two INI options
> which are only added to PHP 7.1 and 7.0 to allow people to immediately
> upgrade to secure defaults without any risk of breaking other apps.
>
I understand what you're going for there, but it's just a bit weird to
have that INI option exist for a weird pair of version ranges and not
forward.   I'd say keep the INI in 7.2 and (perhaps) mark them
deprecated.  There's no sense making that upgrade path unreasonably
difficult.

-Sara

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

Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates

[Sara Golemon]

On Mon, Jul 3, 2017 at 12:49 PM, Anatol Belski  wrote:
> About how to proceed - I'd say the issue is clear and either way
> should be fixed. The RFC chooses the explicit strength approach.
> What I'm a bit concerned about is, that there's no implementation
> by this time, neither for 7.2 nor for lower. Given there are indeed
> just last moments before the feature freeze, for 7.2 it depends on RMs.
>
I've told Niklas on Twitter, but I'll repeat here for the record.  I
fully expect a rush of last-minute RFCs "urgently" needing an
extension of the feature freeze deadline.  These come every new
release as people are shocked to discover that timetables exist.

IMO any RFC which does not have a merged implementation by July 20th*
should assume it's not making it into 7.2, however RFCs will be taken
on a case-by-case basis while in the beta period.  As to this one: It
certainly seems important that we don't let users blindly ignore
terrible certificates.  That's a false sense of security, and is
arguably worse than no security at all.

I expect to allow this RFC as far out as beta2 ASSUMING the
implementation is sensible enough to get a passing vote from
internals.

If it moves things along smoother/quicker, I would suggest to
constrain this discussion as though it were ONLY targeting 7.2, and we
can have a separate discussion about how/when it should be back-ported
to 7.1 and 7.0 since this change does represent a (theoretical**) BC
break.

-Sara

* Yes, this includes ext/sodium, and I'm less inclined to extend
lee-way to that for a number of reasons.
** Legitimately signed sites should not actually be a problem, AIUI.

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

Re: [PHP-DEV] Re: [RFC] [Discussion] Class Naming

[Fleshgrinder]

On 7/3/2017 7:18 PM, Niklas Keller wrote:
> While true, most applications actually depend on the case for class
> names because of autoloaders.
> 
> Regards, Niklas 
> 

Nobody is auto-loading internal classes, they are auto-loaded by PHP.
That is the only thing this vote is about.

PS: Note that I personally would vote for "always PascalCase" because
context awareness is a bad thing when it comes to such things as naming.
However, I have no vote and the current landscape of PHP internals goes
more in the "except acronyms" direction. It is up to the voters, but the
casing is not an issue for this vote, that's all I'm sayin'.

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Re: [RFC] [Discussion] Class Naming

[Niklas Keller]

2017-07-03 17:53 GMT+02:00 Fleshgrinder :

> On 7/3/2017 5:30 PM, Andreas Treichel wrote:
> > With any exception from PascalCase you cannot e.g. generate class names
> > from strings without a explicit mapping table:
> >
> >  >
> > function findParserByRootNode(DomDocument $document)
> > {
> > $tagName = $document->documentElement->tagName;
> > $className = ucfirst($tagName) . 'Parser';
> > if (!class_exists($className)) {
> > throw new RuntimeException('Parser not found for '.$tagName);
> > }
> > return new $className();
> > }
> >
> > $document = new DomDocument();
> > $document->loadXml($xml);
> >
> > $parser = findParserByRootNode($document);
> > $parser->parse($document);
> >
> >
> >
> > acronyms in PascalCase looks strange, but consistent strange.
> >
> >
>
> Not true in PHP because class names are not case sensitive:


While true, most applications actually depend on the case for class names
because of autoloaders.

Regards, Niklas

Re: [PHP-DEV] "Reader" as alternative to Iterator

[Niklas Keller]

2017-07-03 17:50 GMT+02:00 Andreas Hennings :

> On Mon, Jul 3, 2017 at 9:09 AM, Niklas Keller  wrote:
> >
> > Hey Andreas,
> >
> > what you're trying to do here seems to be premature optimization. While
> you
> > save a bunch of method calls, your I/O will be the actual bottleneck
> there.
> > It's entirely fine to implement such logic in userland.
>
> I will let this stand unchallenged, until I have some reproducible data..
>
> >
> > Amp has a similar interface for its streams, but those have only
> string|null
> > as types. If you want to allow all values, you either need a second
> method
> > or need to wrap all values in an object.
> >
> > http://amphp.org/byte-stream/#inputstream +
> > http://amphp.org/amp/iterators/#iterator-consumption
>
> This library looks interesting.
> It seems to do a lot more than I currently need, with its concurrency
> approach.
> I am a bit puzzled by the yield keyword in this code:
>
>  while (($chunk = yield $inputStream->read()) !== null) {
> $buffer .= $chunk;
> }
>
> In my experience with generators so far, you either use yield for
> sending or for receiving. So either "yield $value;" or "$value =
> yield;" In this case it seems to do both.
>

Indeed, it can do both at the same time.


> I assume this is to achieve the concurrency.


Not exactly, it "outputs" a promise and "inputs" the resolution value or
exception once that promise resolves.

Regards, Niklas

Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates

[Niklas Keller]

>
> I haven't followed the discussion back then, but just read through. The
> discussion seems unfinished yet, as far as I understood. The two
> approaches  - the one going by security levels, and the other using
> strength bits as a argument. As for me, security levels were more future
> oriented and the original alike, while have to be emulated with older
> dependencies. On the other hand - giving the strength directly is a an
> explicit approach, even if it's completely different from the latest
> OpenSSL. It were good to hear from Jakub yet.
>
> About how to proceed - I'd say the issue is clear and either way should be
> fixed. The RFC chooses the explicit strength approach. What I'm a bit
> concerned about is, that there's no implementation by this time, neither
> for 7.2 nor for lower. Given there are indeed just last moments before the
> feature freeze, for 7.2 it depends on RMs.
>

This is caused by the approach not being clear, I have an implementation
without options locally.


> In general, I'd prefer to see the discussion to come more or less to the
> conclusion about pro/contra of the concrete approach, especially from the
> POV different OpenSSL versions and future support. If a patch with an
> implementation could make it into 7.2, the backport for lower branches will
> have no choice regarding approach. But, without being able to look at th
> patch, it is hard to say, whether a backport is even doable. For example,
> how it often could be, an implementation of a new stream context option
> might require some additional struct member, etc. Alternatively, what could
> be done - bring the approach discussion and consequently the BC
> implementation in all of 7\.[012] while letting the restrictive part to
> target 7.3. Either way, please let's see the code.
>

I think the best approach for now would be that:

Add two new context options for the "ssl" wrapper:
"insecure_allow_md5_signature" and "insecure_allow_sha1_signature". They
will both default to false starting in PHP 7.2 while the backports to PHP
7.1 and 7.0 will default to true. Additionally there will be two INI
options which are only added to PHP 7.1 and 7.0 to allow people to
immediately upgrade to secure defaults without any risk of breaking other
apps.

Regards, Niklas

RE: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates

[Anatol Belski]

Hi,

> -Original Message-
> From: Niklas Keller [mailto:m...@kelunik.com]
> Sent: Monday, July 3, 2017 3:14 PM
> To: Jakub Zelenka 
> Cc: PHP Internals 
> Subject: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
> 
> 2017-05-30 22:26 GMT+02:00 Jakub Zelenka :
> 
> > On Mon, May 29, 2017 at 9:16 PM, Niklas Keller  wrote:
> >
> >> 2017-05-29 22:00 GMT+02:00 Jakub Zelenka :
> >>
> >>> On Mon, May 29, 2017 at 11:58 AM, Niklas Keller 
> wrote:
> >>>
>  Morning Internals,
> 
>  I have updated the RFC to use a "min_signature_bits" setting instead.
> 
> 
> >>> Wouldn't be better use security levels instead as it is in OpenSSL?
> >>> Of course I mean just for sig level to not re-implement everything.
> >>> Basically having sig_level or something like that...
> >>>
> >>
> >> As we can't use the OpenSSL implementation directly, I don't see any
> >> reason to use arbitrary integers there which you have to look up again.
> >> Maybe we should fine a totally different way.
> >>
> >>
> > Well we are going to implement security levels at some point  anyway
> > as it is the primary way how to control security strength in OpenSSL
> > 1.1+ so people will need to look it up anyway. It is also much easier
> > to use than directly setting security bits IMHO. It might also allow
> > us to simplify implementation in the future (for example if it gets
> > separated to its own verify param in the future, we could use that).
> > Also we will be able to just completely skip that if the main security
> > level is already on that level or higher (it would be already covered by 
> > that).
> >
> > Please mind that this is an openssl extension so we should prefer the
> > API offered by the library and not trying to invent our own solutions.
> >
> > Cheers
> >
> > Jakub
> >
> 
> What's the way to proceed now? Time is running low for the PHP 7.2 feature
> freeze.
> 
I haven't followed the discussion back then, but just read through. The 
discussion seems unfinished yet, as far as I understood. The two approaches  - 
the one going by security levels, and the other using strength bits as a 
argument. As for me, security levels were more future oriented and the original 
alike, while have to be emulated with older dependencies. On the other hand - 
giving the strength directly is a an explicit approach, even if it's completely 
different from the latest OpenSSL. It were good to hear from Jakub yet.

About how to proceed - I'd say the issue is clear and either way should be 
fixed. The RFC chooses the explicit strength approach. What I'm a bit concerned 
about is, that there's no implementation by this time, neither for 7.2 nor for 
lower. Given there are indeed just last moments before the feature freeze, for 
7.2 it depends on RMs.

In general, I'd prefer to see the discussion to come more or less to the 
conclusion about pro/contra of the concrete approach, especially from the POV 
different OpenSSL versions and future support. If a patch with an 
implementation could make it into 7.2, the backport for lower branches will 
have no choice regarding approach. But, without being able to look at th patch, 
it is hard to say, whether a backport is even doable. For example, how it often 
could be, an implementation of a new stream context option might require some 
additional struct member, etc. Alternatively, what could be done - bring the 
approach discussion and consequently the BC implementation in all of 7\.[012] 
while letting the restrictive part to target 7.3. Either way, please let's see 
the code. 

Regards

Anatol 

Re: [PHP-DEV] "Reader" as alternative to Iterator

[Andreas Hennings]

On Mon, Jul 3, 2017 at 6:08 PM, Andreas Hennings  wrote:
> On Mon, Jul 3, 2017 at 5:53 PM, Johannes Schlüter
>  wrote:
>> On Mo, 2017-07-03 at 17:32 +0200, Niklas Keller wrote:
>>
>>> > That distinction is the reason why next() and valid() are different
>>> > methods in iterators.
>
> I would rather say this is the reason why current() and valid() are
> different methods.
> A combination of ->current() and next() would not cause problems.
>
>>>
>>> Not really, Iterator::next() returns void, so could as well return
>>> bool.

Just so we are on the same page:
Changing the behavior of Iterator interface would be a BC break.
Introducing a new interface, and letting Generator implement it, would
not break anything.
(except for the possible nameclash, if the an interface with the same
name already exists in userland outside of a namespace)

I assume we already agree on this, and this was more of a thought experiment.

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

Re: [PHP-DEV] "Reader" as alternative to Iterator

[Andreas Hennings]

On Mon, Jul 3, 2017 at 5:53 PM, Johannes Schlüter
 wrote:
> On Mo, 2017-07-03 at 17:32 +0200, Niklas Keller wrote:
>
>> > That distinction is the reason why next() and valid() are different
>> > methods in iterators.

I would rather say this is the reason why current() and valid() are
different methods.
A combination of ->current() and next() would not cause problems.

>>
>> Not really, Iterator::next() returns void, so could as well return
>> bool.
>
> Well, that story is a bit longer and I cut it short. Let's assume we
> remove valid and use next's return value. Then we don't know if the
> first element exists or not, as next is only called after the first
> iteration. An alternative might be using only current() but then we
> need a special, magic, return value to mark the end oder references.
> Both are bad.

The proposed ->read() method is more or less the same as ->current()
plus ->next(), if ->current() always returns FALSE on end-of-data.
An object that has both ->read() and ->valid() would remove the need
for a special magic return value.

But in many many cases, having a magic return value FALSE is totally acceptable.
Think of fgetcsv(), fread(), or PDOStatement::fetch().

So if we wanted, we could have one interface "SimpleReader" or
"FalseTerminatedReader" with only the ->read() method, and another
method "Reader" with both ->read() and ->valid().

(Sometimes I would like to have a new data type "unique symbol" for
constants that are not strings or integers. So we could say "while
(EOF !== $value = $reader->read());" but this is another topic)

>
> johannes

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

Re: [PHP-DEV] "Reader" as alternative to Iterator

[Andreas Hennings]

On Mon, Jul 3, 2017 at 5:27 PM, Johannes Schlüter
 wrote:
>
> Wouldn't SPL's NoRewindIterator be enough?
>
> $nit = new NoRewindIterator($it);
>
> foreach ($nit as $row) {
>  break;
> }
> foreach ($nit as $row) {
>   // continues same iteration
> }

I had not noticed this class :)

My motivation was to be able to use iterators and readers interchangeably.
Readers are easier to implement as classes.
Iterators have the benefit of the generator syntax.
The idea is to have a library where some stuff is implemented as
reader classes, and some other things are implemented as iterator
classes.

Then for the actual operational code, I need to choose to use either
iterator syntax or reader syntax. So either I need adapters for all
iterators, or I need adapters for all readers.

The NoRewindIterator would make it more viable to work with iterator
syntax on operation level.
So yes, it is a helpful hint. Not sure if it makes me fully happy.

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

Re: [PHP-DEV] Re: [RFC] [Discussion] Class Naming

[Fleshgrinder]

On 7/3/2017 5:30 PM, Andreas Treichel wrote:
> With any exception from PascalCase you cannot e.g. generate class names
> from strings without a explicit mapping table:
> 
>  
> function findParserByRootNode(DomDocument $document)
> {
> $tagName = $document->documentElement->tagName;
> $className = ucfirst($tagName) . 'Parser';
> if (!class_exists($className)) {
> throw new RuntimeException('Parser not found for '.$tagName);
> }
> return new $className();
> }
> 
> $document = new DomDocument();
> $document->loadXml($xml);
> 
> $parser = findParserByRootNode($document);
> $parser->parse($document);
> 
> 
> 
> acronyms in PascalCase looks strange, but consistent strange.
> 
> 

Not true in PHP because class names are not case sensitive:

https://3v4l.org/bcAAC

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] "Reader" as alternative to Iterator

[Johannes Schlüter]

On Mo, 2017-07-03 at 17:32 +0200, Niklas Keller wrote:

> > That distinction is the reason why next() and valid() are different
> > methods in iterators.
> 
> Not really, Iterator::next() returns void, so could as well return
> bool.

Well, that story is a bit longer and I cut it short. Let's assume we
remove valid and use next's return value. Then we don't know if the
first element exists or not, as next is only called after the first
iteration. An alternative might be using only current() but then we
need a special, magic, return value to mark the end oder references.
Both are bad.

johannes

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

Re: [PHP-DEV] "Reader" as alternative to Iterator

[Andreas Hennings]

On Mon, Jul 3, 2017 at 9:09 AM, Niklas Keller  wrote:
>
> Hey Andreas,
>
> what you're trying to do here seems to be premature optimization. While you
> save a bunch of method calls, your I/O will be the actual bottleneck there.
> It's entirely fine to implement such logic in userland.

I will let this stand unchallenged, until I have some reproducible data..

>
> Amp has a similar interface for its streams, but those have only string|null
> as types. If you want to allow all values, you either need a second method
> or need to wrap all values in an object.
>
> http://amphp.org/byte-stream/#inputstream +
> http://amphp.org/amp/iterators/#iterator-consumption

This library looks interesting.
It seems to do a lot more than I currently need, with its concurrency approach.
I am a bit puzzled by the yield keyword in this code:

 while (($chunk = yield $inputStream->read()) !== null) {
$buffer .= $chunk;
}

In my experience with generators so far, you either use yield for
sending or for receiving. So either "yield $value;" or "$value =
yield;" In this case it seems to do both.
I assume this is to achieve the concurrency.

(This is not an argument for or against anything, just an observation)

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

Re: [PHP-DEV] "Reader" as alternative to Iterator

[Andreas Hennings]

Thanks everyone so far for the replies!
I think I need to do some "homework", and come back with benchmarks
and provide real examples.
I remember that the overhead did make a difference in performance, but
I should back that up with real data.

For now just some inline replies.


On Mon, Jul 3, 2017 at 3:42 PM, Sara Golemon  wrote:
> On Sun, Jul 2, 2017 at 10:49 PM, Andreas Hennings  wrote:
>> (I wanted dedicated reader classes for different return types, e.g.
>> one "RowReader", one "AssocReader", one "ObjectReader". So here I
>> would need one adapter class per type. But let's focus on the simple
>> case, where you can use the same reader class.)
>>
> You need that anyway.  If the current iterator returns one type and
> you want to transform that into another type, then you need something
> to actually do that.  Having a reader interface won't magically know
> that you want to change the output type.
>
> If I'm misunderstanding that, and you're saying that the output type
> of the original iterator is already different and you somehow need a
> different proxy to blindly pass through the different type then... No.
> You don't.  A single reader adapter will handle whatever type you pass
> through it.

Yes, the adapters were just blind proxies.
In my own library I had dedicated reader types like
XmlElementReaderInterface, RowReaderInterface (e.g. for CSV),
AssocReaderInterface, ObjectReaderInterface, each with their own
->read() methods like ->getElement(), ->getRow(), ->getAssoc(),
->getObject().
So I ended up writing a distinct iterator adapter for each reader type.

The different interfaces were helpful to prevent using a reader of the
wrong type.
But we would lose this anyway if this was implemented in core. All the
methods would all collapse into just one method ->read().
Maybe some PhpDoc magic could help the IDE to distinguish the reader
type. Currently my IDE does not support such a thing.

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

Re: [PHP-DEV] Re: [RFC] LDAP EXOP

[Côme Chilliet]

Le lundi 3 juillet 2017, 17:04:02 Andreas Treichel a écrit :
> i dont see the benefit to return a single value with a reference.
> 
> Without a reference the function can used as an argument:
> doSomethingWithTheUserName(ldap_whoami($link));

Where do you handle errors in this case?

For me returning a mixed will result in:
$identity = ldap_exop_whoami($link);
if ($identity !== FALSE) {
// do something with $identity
} else {
// handle errors
}

While with the reference it’s cleaner:
if (ldap_exop_whoami($link, $identity)) {
// do something with $identity
} else {
// handle errors
}

It seems both solutions exists in existing LDAP methods:
https://secure.php.net/manual/en/function.ldap-get-option.php
https://secure.php.net/manual/en/function.ldap-get-dn.php

The other thing I liked about using bool return and a reference is that it will 
allow all ldap_exop_* methods to be consistent, all returning a boolean and 
filling as many reference parameters as needed (from 0 to whatever).

> same with the return statement of a method:
> 
> class MyLdap
> {
>  public function getCurrentUser(): string
>  {
>  return ldap_whoami($this->link);
>  }
> }
> 
> class MyLdap
> {
>  function getCurrentUser(): string
>  {
>  ldap_whoami($this->link, $username);
>  return $username;
>  }
> }

This is a valid point.

Côme

signature.asc
Description: This is a digitally signed message part.

Re: [PHP-DEV] "Reader" as alternative to Iterator

[Niklas Keller]

2017-07-03 17:27 GMT+02:00 Johannes Schlüter :

> On Sa, 2017-07-01 at 19:38 +0200, Andreas Hennings wrote:
> > Hello internals,
> > (this is my first email to this list, hopefully I'm doing ok.)
> >
> > ---
> > -
> >
> > Background / motivation:
> >
> > Currently in PHP we have an interface "Iterator", and a final class
> > "Generator"
> > (and others) that implement it.
> >
> > Using an iterator in foreach () is straightforward:
> > foreach ($iterator as $key => $value) {..}
> >
> > However, if we want to iterate only a portion and then continue
> > elsewhere at the position where we stopped, we need to do something
> > like this:
> >
> > for ($iterator->rewind(); $iterator->valid(); $iterator->next()) {
> >   $value = $iterator->current();
> >   [..]
> > }
> >
> > This is unpleasantly verbose, and also adds performance overhead due
> > to additional function calls.
>
> Wouldn't SPL's NoRewindIterator be enough?
>
> $nit = new NoRewindIterator($it);
>
> foreach ($nit as $row) {
>  break;
> }
> foreach ($nit as $row) {
>   // continues same iteration
> }
>
> >
> > Also, manually writing an iterator is quite painful.
> >
> > I sometimes implement "readers" that can be used like this (*):
> >
> > // Gets a reader at position zero.
> > $reader = $readerProvider->getReader();
> > while (FALSE !== $value = $reader->read()) {
> >   [..]
> > }
> >
> > (*) Note that I am using FALSE as an equivalent for "end of data". Of
> > course it would be nice if we had a dedicated constant for this, that
> > does not constrain the range of possible values of the iterator.
>
> That distinction is the reason why next() and valid() are different
> methods in iterators.


Not really, Iterator::next() returns void, so could as well return bool.

Regards, Niklas

[PHP-DEV] Re: [RFC] [Discussion] Class Naming

[Andreas Treichel]

With any exception from PascalCase you cannot e.g. generate class names 
from strings without a explicit mapping table:


documentElement->tagName;
$className = ucfirst($tagName) . 'Parser';
if (!class_exists($className)) {
throw new RuntimeException('Parser not found for '.$tagName);
}
return new $className();
}

$document = new DomDocument();
$document->loadXml($xml);

$parser = findParserByRootNode($document);
$parser->parse($document);



acronyms in PascalCase looks strange, but consistent strange.


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

Re: [PHP-DEV] "Reader" as alternative to Iterator

[Johannes Schlüter]

On Sa, 2017-07-01 at 19:38 +0200, Andreas Hennings wrote:
> Hello internals,
> (this is my first email to this list, hopefully I'm doing ok.)
> 
> ---
> -
> 
> Background / motivation:
> 
> Currently in PHP we have an interface "Iterator", and a final class
> "Generator"
> (and others) that implement it.
> 
> Using an iterator in foreach () is straightforward:
> foreach ($iterator as $key => $value) {..}
> 
> However, if we want to iterate only a portion and then continue
> elsewhere at the position where we stopped, we need to do something
> like this:
> 
> for ($iterator->rewind(); $iterator->valid(); $iterator->next()) {
>   $value = $iterator->current();
>   [..]
> }
> 
> This is unpleasantly verbose, and also adds performance overhead due
> to additional function calls.

Wouldn't SPL's NoRewindIterator be enough?

$nit = new NoRewindIterator($it);

foreach ($nit as $row) {
 break;
}
foreach ($nit as $row) {
  // continues same iteration
}

> 
> Also, manually writing an iterator is quite painful.
> 
> I sometimes implement "readers" that can be used like this (*):
> 
> // Gets a reader at position zero.
> $reader = $readerProvider->getReader();
> while (FALSE !== $value = $reader->read()) {
>   [..]
> }
> 
> (*) Note that I am using FALSE as an equivalent for "end of data". Of
> course it would be nice if we had a dedicated constant for this, that
> does not constrain the range of possible values of the iterator.

That distinction is the reason why next() and valid() are different
methods in iterators.


johannes

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

Re: [PHP-DEV] [RFC] [Discussion] Retry functionality

[Sammy Kaye Powers]

On Tue, Jun 20, 2017 at 12:47 AM, Stanislav Malyshev
 wrote:
> Hi!
>
> Also, having only 2 weeks to discuss about introducing a new language
> keyword sounds like extremely short period. Especially at the summer
> when many people go to vacations. There's no rush, really. 2 weeks is a
> *minimal* time, not the time to strive for in any case.

I'm OK with holding off on the retry RFC to allow more discussion and
give the RFC the TLC that it needs after getting receiving all the
feedback. So we won't be going to vote on the retry RFC today, rather
we'll shoot for PHP 7.3 at a later date. :)

Thanks,
Sammy Kaye Powers
sammyk.me

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

[PHP-DEV] Re: [RFC] LDAP EXOP

[Andreas Treichel]

Hello,

please change the signature form

bool ldap_exop_whoami(resource $link, string &$result)

to

string ldap_whoami(resource $link);

i dont see the benefit to return a single value with a reference.

Without a reference the function can used as an argument:
doSomethingWithTheUserName(ldap_whoami($link));


With a reference a variable is required:
ldap_whoami($link, $username);
doSomethingWithTheUserName($username);


same with the return statement of a method:

class MyLdap
{
public function getCurrentUser(): string
{
return ldap_whoami($this->link);
}
}

class MyLdap
{
function getCurrentUser(): string
{
ldap_whoami($this->link, $username);
return $username;
}
}


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

[PHP-DEV] Re: 7.2 behavior break, Bug #74836 isset on zero-prefixed numeric indexes in array broken

[Sara Golemon]

On Mon, Jul 3, 2017 at 3:03 AM, Dmitry Stogov  wrote:
> Please take a look at https://bugs.php.net/bug.php?id=74836
>
> What is the best option to fix this?
>
I'm more curious *why* we throw out numeric strings starting with
zeros in _zend_handle_numeric_str_ex()

But since the answer to that question probably lies down a long road
to even worse BC-breaksville, how about we revert your IS_CONST
optimization for 7.2 and give it the time it needs for 7.3?

-Sara

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

Re: [PHP-DEV] "Reader" as alternative to Iterator

[Sara Golemon]

On Sun, Jul 2, 2017 at 10:49 PM, Andreas Hennings  wrote:
> (I wanted dedicated reader classes for different return types, e.g.
> one "RowReader", one "AssocReader", one "ObjectReader". So here I
> would need one adapter class per type. But let's focus on the simple
> case, where you can use the same reader class.)
>
You need that anyway.  If the current iterator returns one type and
you want to transform that into another type, then you need something
to actually do that.  Having a reader interface won't magically know
that you want to change the output type.

If I'm misunderstanding that, and you're saying that the output type
of the original iterator is already different and you somehow need a
different proxy to blindly pass through the different type then... No.
You don't.  A single reader adapter will handle whatever type you pass
through it.

> the adapters also make stack traces heavier to look at.
>
That is the only slightly compelling argument I've seen so far.  Not
compelling enough IMO.

> The main purpose of the generator syntax is to simplify the code. The
> need for userland adapters defeated this purpose.
>
ONE adapter, which lives in a library that you don't touch once it's
written. That doesn't defeat your purposes at all.  That is, in fact,
identical to having done the implementation in the core, expect when
done in userland you have the opportunity to use it tomorrow rather
than in December, and the ability to fix any bugs immediately rather
than on a release cycle.

> Native readers would have made generators worthwhile for my use case.
>
You've yet to demonstrate that they are not worthwhile.

> The idea of "dedicated reader types" e.g. Reader could be
> added to "Open questions"..
>
You have yet to demonstrate the need for dedicated and/or templatized
reader types.

-Sara

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

[PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates

[Niklas Keller]

2017-05-30 22:26 GMT+02:00 Jakub Zelenka :

> On Mon, May 29, 2017 at 9:16 PM, Niklas Keller  wrote:
>
>> 2017-05-29 22:00 GMT+02:00 Jakub Zelenka :
>>
>>> On Mon, May 29, 2017 at 11:58 AM, Niklas Keller  wrote:
>>>
 Morning Internals,

 I have updated the RFC to use a "min_signature_bits" setting instead.


>>> Wouldn't be better use security levels instead as it is in OpenSSL? Of
>>> course I mean just for sig level to not re-implement everything. Basically
>>> having sig_level or something like that...
>>>
>>
>> As we can't use the OpenSSL implementation directly, I don't see any
>> reason to use arbitrary integers there which you have to look up again.
>> Maybe we should fine a totally different way.
>>
>>
> Well we are going to implement security levels at some point  anyway as it
> is the primary way how to control security strength in OpenSSL 1.1+ so
> people will need to look it up anyway. It is also much easier to use than
> directly setting security bits IMHO. It might also allow us to simplify
> implementation in the future (for example if it gets separated to its own
> verify param in the future, we could use that). Also we will be able to
> just completely skip that if the main security level is already on that
> level or higher (it would be already covered by that).
>
> Please mind that this is an openssl extension so we should prefer the API
> offered by the library and not trying to invent our own solutions.
>
> Cheers
>
> Jakub
>

What's the way to proceed now? Time is running low for the PHP 7.2 feature
freeze.

I've implemented it manually for https://github.com/amphp/socket/pull/31
now. The captured chain always seems to contain the trusted certificate as
last certificate.

Honestly, what isn't secure for the public internet PKI shouldn't be
considered secure for other contexts. I'd personally be fine with not even
providing a setting other than disabling verify_peer.

Regards, Niklas

[PHP-DEV] Re: 7.2 behavior break, Bug #74836 isset on zero-prefixed numeric indexes in array broken

[Bob Weinand]

Am 03.07.2017 um 09:03 schrieb Dmitry Stogov 
>:

Hi,

Please take a look at https://bugs.php.net/bug.php?id=74836
What is the best option to fix this?

The most consistent way, from my point of view - disabling zero-prefexed 
numeric strings in all cases, but this is a new behavior break.

Thanks. Dmitry.

Hey,

yep, it's probably best to allow only reversible string->integer conversions 
here.
We also shall then emit an E_NOTICE error, just like on normal arrays.

I see no reason to let invalid indices just silently pass on strings.

Bob

Re: [PHP-DEV] "Reader" as alternative to Iterator

[Niklas Keller]

2017-07-03 4:49 GMT+02:00 Andreas Hennings :

> Well, on a current project I made an attempt to write different
> adapters in userland.
> I finally decided that the clutter is not worth.
> So for this project I wrote everything as "readers", and not as iterators.
>
> With a native solution, one could do this:
>
> function generate() {
>   yield 'a';
>   yield 'b';
>   yield 'c';
> }
>
> $it = generate();
>
> while (FALSE !== $v = $it->read()) {
>   print $v . "\n";
> }
>
> With a userland adapter, the code would read like this:
>
> function generate() {
>   yield 'a';
>   yield 'b';
>   yield 'c';
> }
>
> $it = generate();
>
> // This is the added line.
> $reader = new IteratorReaderAdapter($it);
>
> while (FALSE !== $v = $reader->read()) {
>   print $v . "\n";
> }
>
>
> This does add clutter and performance overhead.
> In this example I'd say this is acceptable / survivable.
>
> In the project I was working on, I have multiple layers of "readers":
> - One layer to read raw data from a CSV file.
> - One layer to re-key the rows by column labels.
> - One layer to turn each row into an object, with structured
> properties instead of just string cells.
>
> With the "reader" approach, for each layer I would have one "reader
> provider" class and one "reader" class per layer.
> (In fact I have much more, but let's keep it simple)
> Generator syntax would allow to have only one class per layer.
> But with the additional adapter, we again increase the number of classes.
> (I wanted dedicated reader classes for different return types, e.g.
> one "RowReader", one "AssocReader", one "ObjectReader". So here I
> would need one adapter class per type. But let's focus on the simple
> case, where you can use the same reader class.)
>
> In addition to more classes and more function calls (performance), the
> adapters also make stack traces heavier to look at.
>
> Overall, for this project, I decided that it was not worth it.
>
> The main purpose of the generator syntax is to simplify the code. The
> need for userland adapters defeated this purpose.
> Native readers would have made generators worthwhile for my use case.
>
> The idea of "dedicated reader types" e.g. Reader could be
> added to "Open questions"..


Hey Andreas,

what you're trying to do here seems to be premature optimization. While you
save a bunch of method calls, your I/O will be the actual bottleneck there.
It's entirely fine to implement such logic in userland.

Amp has a similar interface for its streams, but those have only
string|null as types. If you want to allow all values, you either need a
second method or need to wrap all values in an object.

http://amphp.org/byte-stream/#inputstream +
http://amphp.org/amp/iterators/#iterator-consumption

Regards, Niklas

[PHP-DEV] 7.2 behavior break, Bug #74836 isset on zero-prefixed numeric indexes in array broken

[Dmitry Stogov]

Hi,


Please take a look at https://bugs.php.net/bug.php?id=74836

What is the best option to fix this?


The most consistent way, from my point of view - disabling zero-prefexed 
numeric strings in all cases, but this is a new behavior break.


Thanks. Dmitry.