Re: [PHP-DEV] [RFC] Support optional suffix parameter in tempnam

[Côme Chilliet]

Le mardi 8 août 2023, 21:11:01 CEST Athos Ribeiro a écrit :
> Hi internals,
> 
> As a follow-up on my previous message here
> (https://marc.info/?l=php-internals=168912164828942=2),
> I would like to start the discussion on the "Support optional suffix
> parameter in tempnam" RFC.
> https://wiki.php.net/rfc/tempnam-suffix-v2

Hello,

The RFC does not explain what benefits brings using tempnam($directory, 
$prefix, $suffix) over using tempnam($directory, $prefix).$suffix , which you 
can already use?

Côme

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

Re: [PHP-DEV] Deprecate ldap_connect with host and port as separate arguments

[Côme Chilliet]

Le vendredi 27 janvier 2023, 10:00:35 CET Andreas Heigl a écrit :
> Hey Folks.
> 
> I think it would be a good idea to deprecate calling ldap_connect with 2 
> parameters host and port.

Hello,

My long term plan was to replace it by a constructor for the new 
\LDAP\Connection class that only accepts the URI syntax. Which would also be 
better because ldap_connect is a really confusing name as it does not actually 
connect to anything.

But I’m unfamiliar with how to write object methods into PHP modules, and I do 
not have much time to allocate to php-ldap.

If you are interested into working on some OO methods for php-ldap classes, I 
have a ton of ideas on how to make it awesome.

Côme

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

Re: [PHP-DEV] [RFC] Destructuring Coalesce

[Côme Chilliet]

Le dimanche 16 octobre 2022, 23:11:05 CET Bob Weinand a écrit :
> Hey,
> 
> I've written a small RFC about adding coalesce ability to list() 
> destructuring.
> 
> This should enhance the ability to easily, concisely and readably destructure 
> arrays with default values.
> 
> https://wiki.php.net/rfc/destructuring_coalesce 
> 
> 
> Bob

Hello,

I voted no as the syntax is too confusing. It reads as if coalescing would 
happen on the var while it happens on the array value.
It means $a ?? 'value' would mean something different when in a list context.

It also looks wrong with keys:
list("name" => $name ?? "unknown") = json_decode($json) ?: [];
I would expect:
list("name" ?? "unknown" => $name) = json_decode($json) ?: [];

But event then it looks fishy since "name" is a key and "unknown" is a value.

I understand the need but I just can’t see a good syntax for it, and the one 
chosen in the RFC sure feels not good enough for integration.

Côme

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

Re: [PHP-DEV] Error behaviour for max_input_vars

[Côme Chilliet]

Hello,

Le mardi 13 septembre 2022, 19:58:42 CEST Mel Dafert a écrit :
> Hi internals,
> 
> I recently ran into issues with the ini setting `max_input_vars`.
> By default, it will truncate input variables in `$_POST` etc. to the
> first 1000, and issue a E_WARNING.

I also ran into this a few years ago and it is really annoying. I agree we 
need a reliable way of catching this error.

> In summary, I believe this can only be solved inside of PHP itself, by
> allowing to configure a way for `max_input_vars` to abort the request
> instead of truncating the input.
> The options I see feasible are:
> - A new ini setting `max_input_vars_abort` (default to 0), which, if set
> to 1, will abort the request if there are more input variables than allowed.
> - A method to reliably detect whether the input vars were truncated (eg.
> `function has_post_been_truncated(): bool`), so the application can decide
> whether to abort or not.
> - Deciding that `max_input_vars` is not relevant anymore and should be
> handled by the likes of Apache and NGINX, thus changing the default to
> `0` and removing the setting
>  over a deprecation period.

All 3 solutions seems a nice improvement from current situation.

Côme

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

Re: [PHP-DEV] RFC [Discussion]: Improve unserialize() error handling

[Côme Chilliet]

Le lundi 5 septembre 2022, 19:20:00 CEST Tim Düsterhus a écrit :
> RFC: Improve unserialize() error handling
> https://wiki.php.net/rfc/improve_unserialize_error_handling

Is the new UnserializationFailedException class extending any other Exception 
class ? This is not explained in the RFC.

Côme


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

Re: [PHP-DEV] [RFC] [Vote] Pre-vote announcement for Random Extension 5.x

[Côme Chilliet]

Le 31 mai 2022 11:54:18 GMT+02:00, Go Kudo  a écrit :
>Hi internals.
>
>Although I have explained that due to the global turmoil I will delay
>voting on the RFC as long as possible, it is time to start voting on the
>RFC in order to get the implementation to full status by the PHP 8.2
>Feature Freeze.
>
>I apologize for the delay in responding to the points you had already
>pointed out. It has been addressed as follows.
>
>- Random\Engine\PCG64::__construct() now takes an `int|string` $inc as its
>second argument
>- This makes it fully compatible with the PCG64 original implementation
>- Fixed an algorithm implementation error in PCG64
>- Fixed compatibility issues with PHP 8.2 in test cases
>- More detailed description in RFC
>
>Previous discussion thread: https://externals.io/message/117295
>
>Voting will begin at 2022-06-14 00:00:00 (UTC).
>
>https://wiki.php.net/rfc/rng_extension
>
>Regards,
>Go Kudo

The first section starts with "However", which sounds like an error from a text 
reorganization?
Also:
"adding any randomization functions between the seeding the intended usage 
would break the code. " -> missing "and" I suppose
"Even with JIT enabled, the native implementation is not far behind. " -> it 
*is* far behind no? It's not even behind but ahead as I see it so maybe I just 
misunderstand this comment.

Côme

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

Re: [PHP-DEV] [RFC][Under discussion] Fetch properties in const expressions

[Côme Chilliet]

Le 28 mai 2022 11:44:13 GMT+02:00, Ilija Tovilo  a 
écrit :
>Hi everyone
>
>I'd like to start a discussion on a simple RFC to allow fetching
>properties in constant expressions.
>https://wiki.php.net/rfc/fetch_property_in_const_expressions
>
>The RFC proposes adding support for fetching properties in constant
>expressions using the -> operator. I'm looking forward to your
>feedback.

It is not clear to me why this allows using -> on enums but not on other 
objects.

Can you clarify why the following is not allowed:

var;
  static $staticobj = new Thing();
  function f($p = self::$staticobj->var) {}
}

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

Re: [PHP-DEV] [VOTE] Undefined Property Error Promotion

[Côme Chilliet]

Le lundi 25 avril 2022, 18:19:33 CEST Rowan Tommins a écrit :
> Look at how the untyped property behaves in this example: 
> https://3v4l.org/nClNs The property disappears from var_dump(), but is 
> not actually deleted from the object, as seen by it still being private 
> when assigned a new value. Given that we have the magic "uninitialized" 
> state, and we're proposing to make reading an unset property an error, 
> it would make more sense for it to show as '["untyped":"Foo":private] => 
> uninitialized(mixed)'

I second that it would make sense for an untyped property to behave the same as 
a typed one with type mixed.
Getting a behavior change by adding a mixed typing to an untyped property is 
highly unexpected.

Côme

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

Re: [PHP-DEV] [VOTE] Undefined Variable Error Promotion

[Côme Chilliet]

Le lundi 14 mars 2022, 18:18:55 CET Mark Randall a écrit :
> I have started the vote for promoting undefined variable access to throw 
> an Error exception.
> 
> The vote will run for 2 weeks until March 28th 2022.
> 
> https://wiki.php.net/rfc/undefined_variable_error_promotion

This does not mention properties, are they concerned by the change? What about 
array keys?

Côme

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

Re: [PHP-DEV] [RFC] [VOTE] Allow null and false as stand-alone types

[Côme Chilliet]

Le samedi 12 mars 2022, 19:30:00 CET G. P. B. a écrit :
> true is not a type in PHP compared to false, therefore it is not included.
> I'm working on a proposal to add true as a type to PHP, but that's a
> seperate RFC and discussion.

Was there ever an RFC for adding literal values to the type system?
This would solve all these problems by allowing stuff like:

function foobar(): "foo"|"bar"|true {
}

Côme

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

Re: [PHP-DEV] [VOTE] User Defined Operator Overloads

[Côme Chilliet]

Hello,

From the RFC:

> If the left operand produces a TypeError due to the parameter types listed in 
> the implementation, the operation is not retried with the right operand and 
> the error is instead returned immediately. This is to help developers 
> encounter errors in their program logic as early as possible.

This feels wrong if I understand correctly.

Let’s say I create a class A and I want to add support for "2 / new A()", which 
by default does not work.

I can do
class A
{
  operator /(int $other, OperandPosition $operandPos): mixed
 {
return "example";
 }
}

Now someone wants to build on my work, and add a class B that supports "new A() 
/ new B()".

class B
{
  operator /(A $other, OperandPosition $operandPos): mixed
 {
return "example";
 }
}

This will not work because it will first try A->{'/'}(B) that throws a 
TypeError? So it means what I was able to do for floats, cannot be done for my 
new classes afterwards? This is inconsistent I think. It also means it is not 
possible to extend any existing class with operators interacting with a new 
class, meaning you can only use operators among classes aware of each other, 
most likely from the same package/library.

Also, this was stated already I think but I did not see an answer, from RFC 
example:
> class Matrix {
> public function __construct(readonly public array $value) {}
>  
> public operator *(Matrix $other, OperandPosition $operandPos): Number
> {
> if ($operandPos == OperandPosition::LeftSide) {
> // Count of my columns needs to match
> // count of $other rows
> } else {
> // Count of my rows needs to match
> // count of $other columns
> }
> }
> }

The second branch of the if is dead code, as $matrix1 * $matrix2 will always 
call $matrix1->{'*'}($matrix2, LeftSide) and never the other way around.
This means that $operandPos is useless in all cases where operators are only 
typed againts the same type, and points to this design solution being wrong.

There is «Why not interfaces?» in the FAQ, does that mean that operators cannot 
be added in interfaces? This is not stated clearly in the RFC.

Also, it is not clear if operator overload will affect comparison operations 
used in core functions such as in_array, sort and so on.
Does implementing operator == allows using in_array to find an object in an 
array?
Which of these internal functions use == and which use ===, which is not 
overloadable?
Does implementing operator <=> allows sorting of arrays containing my objects?

Côme

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

Re: [PHP-DEV] [VOTE] Locale-independent case conversion

[Côme Chilliet]

Le jeudi 25 novembre 2021, 06:05:37 CET Tim Starling a écrit :
> Voting is now open for my RFC on locale-independent case conversion.
> 
> https://wiki.php.net/rfc/strtolower-ascii

Hello,

The RFC is missing information about alternatives:
Do all of these function have an mbstring version?
Are those locale dependant or have an option for it?

To reuse the example from the RFC, if I want to convert a UTF string to 
uppercase using Turkish rules and get dotted capital I, what should I use?

Côme

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

Re: [PHP-DEV] PHP 8.1.0RC6 available for testing

[Côme Chilliet]

Le mardi 16 novembre 2021, 13:40:30 CET Christoph M. Becker a écrit :
> On 16.11.2021 at 13:11, Côme Chilliet wrote:
> > I have a difference in behavior between PHP 8.1 RC6 and my system PHP for 
> > the function imagettfbbox.
> > It is hard to know if this is a problem with 8.1 really because I had to 
> > download and build imagick through pecl to be able to run this.
> 
> imagettfbbox() is part of ext/gd which is a bundled extension.  It has
> nothing to do with imagick (besides both are for image manipulation).

Thank you for the clarification, I got lost in all theses libraries…

> This might be due to different libfreetype, libgd or libraqm versions
> (or possibly libraqm wasn't enabled for one of the builds), or because
> one build used system libgd and the other used the bundled GD.

The PHP from my system is 7.4 and says:
$ php --info|grep -i freetype -i
FreeType Support => enabled
FreeType Linkage => with freetype
$ php --info|grep -i gd -i
/etc/php/7.4/cli/conf.d/20-gd.ini,
gd
GD Support => enabled
GD headers Version => 2.2.5
GD library Version => 2.2.5
gd.jpeg_ignore_warning => 1 => 1

The one I built says:
$ ~/dev/php-src-git/sapi/cli/php --info|grep -i freetype
Configure Command =>  './configure'  '--with-ldap' '--with-ldap-sasl' 
'--with-zip' '--with-curl' '--with-openssl' '--with-zlib' '--enable-mbstring' 
'--enable-pcntl' '--enable-intl' '--with-password-argon2' '--with-freetype' 
'--with-jpeg' '--enable-gd' '--with-imagick'
FreeType Support => enabled
FreeType Linkage => with freetype
FreeType Version => 2.10.1
$ ~/dev/php-src-git/sapi/cli/php --info|grep -i gd
Configure Command =>  './configure'  '--with-ldap' '--with-ldap-sasl' 
'--with-zip' '--with-curl' '--with-openssl' '--with-zlib' '--enable-mbstring' 
'--enable-pcntl' '--enable-intl' '--with-password-argon2' '--with-freetype' 
'--with-jpeg' '--enable-gd' '--with-imagick'
gd
GD Support => enabled
GD Version => bundled (2.1.0 compatible)
gd.jpeg_ignore_warning => 1 => 1

So it seems the one I built used a bundled older version of GD? How should I 
change my configure line to use the same GD as the other one?

Côme

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

Re: [PHP-DEV] PHP 8.1.0RC6 available for testing

[Côme Chilliet]

Hello,

I have a difference in behavior between PHP 8.1 RC6 and my system PHP for the 
function imagettfbbox.
It is hard to know if this is a problem with 8.1 really because I had to 
download and build imagick through pecl to be able to run this.


  int(1)
  [1]=>
  int(0)
  [2]=>
  int(8)
  [3]=>
  int(0)
  [4]=>
  int(8)
  [5]=>
  int(-12)
  [6]=>
  int(1)
  [7]=>
  int(-12)
}
$ php ~/dev/test-freetype.php
array(8) {
  [0]=>
  int(0)
  [1]=>
  int(1)
  [2]=>
  int(10)
  [3]=>
  int(1)
  [4]=>
  int(10)
  [5]=>
  int(-12)
  [6]=>
  int(0)
  [7]=>
  int(-12)
}

As you can see the resulting bounding box is not the same, for the same font. 
This messes up our avatar generation, which ends up a few pixels wrong on the 
centering of the initial in the image.

Does anyone knows where this can come from, and if by changing how I build/link 
imagick I can get the same result on both binaries?

Côme

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

Re: [PHP-DEV] [RFC] Migrating to GitHub issues

[Côme Chilliet]

Le lundi 15 novembre 2021, 15:49:04 CET Deleu a écrit :
> Gitlab is not where the wide PHP Community is located. Composer,
> widely-used and adopted packages, frameworks, PSRs, PHP itself and PHP Docs
> are all hosted on GitHub. Choosing something else increases the barrier for
> newcomers to become contributors. I speak from experience that when I tried
> to contribute to Alpine Linux, one of the major turn off was GitLab
> hosting. I had already decided to spend time and effort learning about the
> project and then having to learn about their ticketing system and git
> repository is just unnecessary extra work.

This is exactly the problem with moving to Github, we are forcing everyone to 
come with us, as others are inciting us to go there by being there (composer, 
…).
Then people only know how to use Github and we are stuck there forever.

If we survived all these years with bugs.php.net, we should be alright with 
gitlab for sure.

I think the PHP project could lead the way out of github instead of following 
the others in.

Côme

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

Re: [PHP-DEV] [RFC] Migrating to GitHub issues

[Côme Chilliet]

I strongly agree with Derick on this matter.

Le lundi 15 novembre 2021, 12:06:54 CET Nikita Popov a écrit :
> For better or worse, GitHub is where nearly all open-source projects are
> hosted, which means that pretty much anyone involved in open-source has an
> account there and is familiar with the workflows. 

I do think that this is for worse, and that this situation exists because of 
decision like the one PHP is about to make. Saying we should use github because 
other projects use it is part of the problem. If PHP makes the switch we are 
encouraging other projects to do the same as well. We would be actively 
participating in this centralisation.

> It is also where PHP
> hosts it's repos and where we accept pull requests. 

Which I also think is a problem. A smaller one because of how git is 
distributed, but still annoying. The decision to move to github for the 
repositories was done in a hurry because of a security issue. It was the right 
decision to answer to the urgency of the situation back then I think, but it 
should not be used as a reason to go deeper down the rabbit hole.

> An alternative issue
> tracker has to compete not just on technical grounds, but also on
> integration, familiarity and network-effect. For an open-source project,
> these aspects are quite important when it comes to interaction with casual
> contributors.
> 
> Working at JetBrains, proposing YouTrack instead of GH issues has certainly
> crossed my mind -- there is no doubt that at a technical level, it's a much
> better bug tracker than GH issues. But that's simply not the right question
> to ask. The right question is whether, given our rather simple
> requirements, is it sufficiently better to overshadow the other benefits of
> GitHub issues for an open-source project? I don't think so. We just need GH
> issues to be "good enough" for our purposes, and I think that at this point
> it is.
> 
> I'll also mention that the discussion about this migration has been going
> on for six months, and in that time all I've ever seen are vague mentions
> of alternatives, but nobody has provided any in-depth analysis that goes
> beyond a simple name drop. I went through the trouble of providing a
> detailed evaluation of how the GitHub issues migration will look like,
> while the alternatives are still at the state of "Phabricator is a thing"
> (ooops, it actually isn't -- it managed to be discontinued while the
> discussion was going on!)

I would like to suggest gitlab.com, which does provide hosting for free for 
opensource projects: https://about.gitlab.com/solutions/open-source/
Anyone with a github account can use it to log in.
It should be easy to migrate to any other gitlab instance if needed. There are 
even plans to one day have federation over gitlab instances. Not anytime soon, 
but likely sooner than github which is only hosted by Microsoft.

Côme

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

Re: [PHP-DEV] Re: Unwrap reference after foreach

[Côme Chilliet]

Le 14 novembre 2021 18:13:18 GMT+01:00, Nikita Popov  a 
écrit :
>I have ultimately decided to withdraw this proposal.
>
>Regards,
>Nikita

This is sad to hear, because this is a really big footgun, which has hit me in 
the past. I ended up adding a codestyle rule forcing byref foreach to be 
followed by an unset to avoid this.

I understand making a special case for one syntax and not the other is 
unsatisfying but I was hoping for an other outcome.


Côme

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

Re: [PHP-DEV] Automatic performance benchmarking: PHP 8.1 is ~30% faster than PHP 7.4

[Côme Chilliet]

Le 12 novembre 2021 11:18:50 GMT+01:00, "Máté Kocsis"  
a écrit :
>
>Furthermore, I'd have some questions regarding this project:
>- Would you welcome automatic emails on internals (or on a dedicated
>mailing list), just like how
>Intel did it? I'm not sure about the frequency, but in my opinion,
>1-2/month would be a sensible one, given there is interest in it.

I would favor having this on a website, with an atom/rss feed. But I'm not 
against having it on the ML, but more like when there is an RC or when some 
change have significant impact.

>- As always, I'm happy to receive feedback and improvements (ideally
>along
>with an implementation :) ). For example, currently I've started
>working on
>some visualization and chart support, but frontend stuff is not my area
>of
>expertise, so I'm progressing a bit slower than normally. Also, the
>statistical foundations could be reviewed, and possibly improved.

The link to the results in the readme points to 
https://kocsismate.github.io/php-version-benchmarks/index.html which is empty. 
Maybe this is known.
Charts 

This quite nice!
Côme

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

Re: [PHP-DEV] [RFC] Allow null as standalone type

[Côme Chilliet]

Le lundi 4 octobre 2021, 10:09:12 CEST Nikita Popov a écrit :
> If we make this change, I would however suggest to also support "false" as
> a standalone type. I think this change primarily has benefits from a
> typesystem completeness perspective rather than a strong practical need.
> From that angle, it would be nice if all types that are usable in a union
> are also usable as standalone types, rather than shifting the special case
> from null to false.

It feels weird/wrong to slowly add values in the type system like this, rather 
than directly supporting static values as type hints.

Why would function a(): null|false {} be legal but function b(): null|0 would 
not?

This is inconsistent to me. And adding null, then false, then true for the sake 
of completeness feels like avoiding to treat the static value as type hint 
subject.

Côme

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

Re: [PHP-DEV] [RFC] Deprecate partially supported callables

[Côme Chilliet]

Le Thu, 2 Sep 2021 16:32:32 +0200,
Nikita Popov  a écrit :

> Hi internals,
> 
> Currently, there are some callables that are accepted by the "callable"
> type, but which cannot be used with $callable() syntax. This RFC proposes
> to deprecate support for such "callables":
> 
> https://wiki.php.net/rfc/deprecate_partially_supported_callables

It took me some time to understand that this was not a proposal to remove
 support for all array/string representation of callables.
This should be made clearer if possible, maybe even list the callable kinds
 which will not be deprecated.

Côme

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

Re: [PHP-DEV] Resources and object resources

[Côme Chilliet]

Le Tue, 31 Aug 2021 15:56:42 +0200,
Côme Chilliet  a écrit :
> It seems to be consistent accross versions: https://3v4l.org/BHtAh
> 
> But what will happen when LDAP connections are turned into objects in 8.1?
> Will they also become int(0) upon serialization or will they behave in an
> other way? I could not find a case of resource that became an object and is
> allowed on 3v4l to test this. There is no LDAP or CURL in there.

Quick followup on this, I found a case that can be tested on 3v4l:
https://3v4l.org/EKFP0

-> Fatal error: Uncaught Exception: Serialization of 'XMLParser' is not allowed
in /in/EKFP0:13

So it seems objects of this kind throw when serialized (I hope they all do
that). It is not clear to me how that behaves with session, will it throw as
soon as affected to $_SESSION, or at the end of the request?

https://www.php.net/manual/en/class.xmlparser.php -> does fully opaque implies
non serializable?

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

[PHP-DEV] Resources and object resources

[Côme Chilliet]

Hello,

Resources cannot be serialized.
This is mentionned on https://www.php.net/manual/en/function.serialize.php ,
 but one can easily miss it.
The information does not seem to appear on
https://www.php.net/manual/en/language.oop5.serialization.php and
https://www.php.net/manual/en/language.types.resource.php

And nowhere does it says what happens if you serialize an object with a
 resource in a property.

Now most resources are replaced by classes in the recent versions of PHP.
Because of this, it is advised to replace tests like
(is_resource($object->res)) with ($object->res !== FALSE).

So, I tried to do this in my application with LDAP connections, which will be
objects in PHP 8.1.

And the application broke, because when unserializing from session an object
containting an LDAP connection, the property is set to int(0). So is_resource()
and !== FALSE will not have the same result.

I cannot find any documentation page mentionning that resources are turned into
int(0) upon serialization.

It seems to be consistent accross versions: https://3v4l.org/BHtAh

But what will happen when LDAP connections are turned into objects in 8.1? Will
they also become int(0) upon serialization or will they behave in an other way?
I could not find a case of resource that became an object and is allowed on
3v4l to test this. There is no LDAP or CURL in there.

Côme

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

Re: [PHP-DEV] [RFC] Deprecate dynamic properties

[Côme Chilliet]

Le Wed, 25 Aug 2021 12:02:49 +0200,
Nikita Popov  a écrit :
> Hi internals,
> 
> I'd like to propose the deprecation of "dynamic properties", that is
> properties that have not been declared in the class (stdClass and
> __get/__set excluded, of course):
> 
> https://wiki.php.net/rfc/deprecate_dynamic_properties

If I understand correctly the RFC, in these two classes:

class A {
public $prop;
 
public function __construct() {
unset($this->prop);
}
}

class B {
public $prop;
}

The property $prop is not in the same state in the end? What is the difference?
isset returns FALSE for both, no? And property_exists?

Is it something that was the same before the RFC and would be different after,
or is it already two different cases and how?

Côme

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

Re: [PHP-DEV] [Vote] Partial Function Application

[Côme Chilliet]

Le Thu, 17 Jun 2021 08:30:43 -0500,
"Larry Garfield"  a écrit :
> > > The ? character was chosen for the placeholder largely because it was
> > > unambiguous and easy to implement. Prior, similar RFCs (such as the
> > > original Pipe Operator proposal from several years ago) used the $$
> > > (lovingly called T_BLING) sigil instead. So far no compelling argument
> > > has been provided for changing the character, so the RFC is sticking
> > > with ?.   
> > 
> > The main argument for $$ is to be able to have partial methods with $$->,
> > this should be stated in this paragraph.  
> 
> That's not something that was ever brought up in the discussion.

Finally found where I read that, it’s in an other RFC:
https://wiki.php.net/rfc/first_class_callable_syntax#partial_function_application

Côme

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

Re: [PHP-DEV] [Vote] Partial Function Application

[Côme Chilliet]

Le Thu, 17 Jun 2021 08:37:23 -0500,
"Larry Garfield"  a écrit :

> On Thu, Jun 17, 2021, at 2:54 AM, Côme Chilliet wrote:
> > > $c = stuff(...);
> > > $c = fn(int $i, string $s, float $f, Point $p, int $m = 0)  
> > >   => stuff($i, $s, $f, $p, $m);  
> >   
> > > $c = stuff(1, 'hi', 3.4, $point, 5, ...);
> > > $c = fn(...$args) => stuff(1, 'hi', 3.4, $point, 5, ...$args);  
> > 
> > Why is there an additional variadic parameter in this one?  
> 
> ... means "zero or more".  In this case, it means zero, that is, it creates a
> closure that requires no arguments and will call the original function with
> all of the provided values later.  This is the "deferred function" use case
> mentioned further down.

I still do not understand why there is an added variadic parameter when
 using ... in stuff(1, 'hi', 3.4, $point, 5, ...); but not when using it in
 stuff(...);
What happens when we use stuff(1, 'hi', 3.4, $point, ...); ?

> > Also, in the second set of examples:  
> > > function things(int $i, float $f, Point ...$points) { ... }  
> >
> > > // Ex 13
> > > $c = things(...);
> > > $c = fn(int $i, float $f, ...$args) => things(...[$i, $f, ...$args]);  
> >
> > > // Ex 14
> > > $c = things(1, 3.14, ...);
> > > $c = fn(...$args) => things(...[1, 3.14, ...$args]);  
> > 
> > What happens to the typing of the variadic parameter here? Why is it
> > removed?
> > 
> > It would feel natural that the ... means "copy the rest of the parameters
> > from signature". Here it seems it sometimes mean that, and sometimes mean
> > "accept an additional variadic parameter and pass it along".  
> 
> Internally placeholders do mean the former.  A trailing variadic, though, can
> accept extra arguments of potentially not pre-defined types, so it sort of
> straddles the line.  Variadics make things weird. :-)  (Dating from PHP
> 5.6.)  In the majority case, though, thinking of them as "copy the rest of
> the arguments" is accurate.

I do not understand why Points ...$points becomes untyped ...$args when using
 things(...), while when using stuff(...) earlier no typing was lost.

Côme

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

Re: [PHP-DEV] [RFC] New in initializers

[Côme Chilliet]

Le Wed, 16 Jun 2021 10:16:37 +0200,
Nikita Popov  a écrit :

> 1. Eagerly evaluate initializers on declaration. This is what I tried in an
> earlier revision of the RFC, and I don't think that approach works. It
> breaks existing code and has various other unpleasant complications.
> 2. Precisely specify the current behavior. I don't want to do this either,
> because the exact places where evaluation happens are something of an
> implementation detail. If in the future we find it convenient to separate
> evaluation of non-static properties on object instantiation from evaluation
> of static properties and class constants (which are not strictly needed at
> that point), I'd like to retain the liberty to make such a change.
> 3. Do not specify an evaluation order, beyond that evaluation happens at
> certain uses of the class. Evaluation order may change across PHP versions.
> If your code relies on any particular order, your code is broken.

If option 3 is considered, it means the evaluation order may change, if we can
change the evaluation order, why not go for option 1? I do not understand which
existing code can break with option 1 and be fine with option 3, it means this
code relies on undefined behaviors, no?

Côme

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

Re: [PHP-DEV] [Vote] Partial Function Application

[Côme Chilliet]

Le Wed, 16 Jun 2021 11:16:28 -0500,
"Larry Garfield"  a écrit :

> Hi folks.  The vote for the Partial Function Application RFC is now open, and
> will run until 30 June.
> 
> https://wiki.php.net/rfc/partial_function_application

From the RFC:

> The ? character was chosen for the placeholder largely because it was
> unambiguous and easy to implement. Prior, similar RFCs (such as the original
> Pipe Operator proposal from several years ago) used the $$ (lovingly called
> T_BLING) sigil instead. So far no compelling argument has been provided for
> changing the character, so the RFC is sticking with ?. 

The main argument for $$ is to be able to have partial methods with $$->, this
 should be stated in this paragraph.

Côme

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

Re: [PHP-DEV] [Vote] Partial Function Application

[Côme Chilliet]

Le Wed, 16 Jun 2021 11:16:28 -0500,
"Larry Garfield"  a écrit :

> Hi folks.  The vote for the Partial Function Application RFC is now open, and
> will run until 30 June.
> 
> https://wiki.php.net/rfc/partial_function_application

I do not understand how this ... placeholder works, it feels inconsistent.

From the examples:

> $c = stuff(...);
> $c = fn(int $i, string $s, float $f, Point $p, int $m = 0)
>   => stuff($i, $s, $f, $p, $m);

> $c = stuff(1, 'hi', 3.4, $point, 5, ...);
> $c = fn(...$args) => stuff(1, 'hi', 3.4, $point, 5, ...$args);

Why is there an additional variadic parameter in this one?

If I remove the 5:
> $c = stuff(1, 'hi', 3.4, $point, ...);
I get this right?:
> $c = fn(int $m = 0) => stuff(1, 'hi', 3.4, $point, $m);

Why the ... does not produce 0 parameters when there are none left?

Also, in the second set of examples:
> function things(int $i, float $f, Point ...$points) { ... }
 
> // Ex 13
> $c = things(...);
> $c = fn(int $i, float $f, ...$args) => things(...[$i, $f, ...$args]);
 
> // Ex 14
> $c = things(1, 3.14, ...);
> $c = fn(...$args) => things(...[1, 3.14, ...$args]);

What happens to the typing of the variadic parameter here? Why is it removed?

It would feel natural that the ... means "copy the rest of the parameters from
 signature". Here it seems it sometimes mean that, and sometimes mean "accept an
 additional variadic parameter and pass it along".

Côme

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

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

[Côme Chilliet]

Hello,

Le Tue, 15 Jun 2021 12:53:47 +0200,
Nikita Popov  a écrit :
> Feedback on the proposed deprecations is appreciated. Personally, the two
> I'm unsure about are "get_class(), get_parent_class() and
> get_called_class() without argument" which are mostly stylistic in nature,
> and "strftime() and gmtstrftime()", where the non-portability issues are
> possibly not so bad that a disruption of existing users is worthwhile.

I use get_called_class() a lot, which is way clearer than static::class as the
 name describe what it does.
I think I am not the only one as I find occurences of it in several projects I
 have in my vendor/ folder, like rector and codesniffer (not the latest version
 through, maybe they changed it).

Forcing people to use static::class will make them have a better
 understanding/instinct of what static:: does, but is that worth forcing a
 change on a working code for something less descriptive, I’m not convinced.

Côme

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

Re: [PHP-DEV] [RFC][Draft] Body-less __construct

[Côme Chilliet]

Le Tue, 11 May 2021 10:58:57 +0200,
Nikita Popov  a écrit :

> If we allow it, I would restrict it to specifically the case of a) a
> promoted constructor b) which has *only* promoted parameters. I don't think
> we should allow replacing "{}" with ";" for methods in the general case.

This would create a subtle difference of allowed syntax between a constructor
 and an other method, and between a constructor with promoted parameters and
 without. I think we should avoid this.

I even thought we merged changes to make constructors more like the other
 methods, but I just checked and it seems the RFCs to allow ": void" on
 constructors were declined.

Côme

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

Re: [PHP-DEV] [RFC] Phasing out Serializable

[Côme Chilliet]

Le Tue, 23 Mar 2021 17:01:40 +0100,
Nicolas Grekas  a écrit :
> Picking up a loose thread:
> > https://wiki.php.net/rfc/custom_object_serialization introduced a
> > replacement for Serializable in PHP 7.4, so it's time to think about
> > deprecating and removing the old mechanism:
> >
> > https://wiki.php.net/rfc/phase_out_serializable
> >
> > This RFC follows a rather conversative approach. In PHP 8.1 there will be a
> > deprecation warning if Serializable is implemented without also
> > implementing __serialize() and __unserialize(). In PHP 9.0, support for
> > Serializable is dropped internally, and only the interface retained. In PHP
> > 10.0 the interface is dropped as well.
> >  

It is not clear neither in https://wiki.php.net/rfc/custom_object_serialization
 nor in the documentation if it is possible to call parent::__serialize() to
 only add a few fields to serialization.

Is this legal/correct/useful:

public __serialize ( ) : array
{
  $data = parent::__serialize();
  $data['specialField'] = $data['special']->complicatedStuff();
  unset($data['special']);
  return $data;
}

public __unserialize ( array $data ) : void
{
  $data['special'] = new SpecialComplicatedThing($data['specialField']);
  unset($data['specialField']);
  parent::__unserialize($data);
}

(And as I understand it, it means declaring __unserialize to do something after
parent::__unserialize() would be the same as declaring __wakeup?)

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

[PHP-DEV] capture_peer_cert support from stream_socket_server

[Côme Chilliet]

Hello,

It seems that is does not work to pass option capture_peer_cert to
 stream_socket_server context in order to get the client certificate used in the
 TLS handshake.

Is that how it is supposed to work, and is it broken?

I tried the following:
$context = stream_context_create(
[
'ssl' => [
'allow_self_signed' => true,
'SNI_enabled'   => true,
'SNI_server_certs'  => ['example.com' => '/path/to/cert.pem'],
'capture_peer_cert' => true,
]
]
);
$socket = stream_socket_server(
'tcp://[::]:' . $port,
$errno,
$errstr,
STREAM_SERVER_BIND | STREAM_SERVER_LISTEN,
$context,
);

if ($socket === false) {
throw new \Exception($errstr, $errno);
} else {
while ($conn = stream_socket_accept($socket, -1, $peername)) {
$tlsSuccess = stream_socket_enable_crypto(
$conn,
true,
STREAM_CRYPTO_METHOD_TLS_SERVER
);
if ($tlsSuccess !== true) {
fclose($conn);
continue;
}
var_dump(stream_context_get_options($conn));
}
}

No peer_certificate option is created when a client connects with a certificate.
Despite what https://www.php.net/manual/en/context.ssl.php says.

This is a problem for implementing client certificate support into Gemini
 servers written in PHP, such as https://tildegit.org/sumpygump/orbit and
 https://framagit.org/MCMic/gemini-server

Côme

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

Re: [PHP-DEV] Suggestion: Inconsistency: Allow array spread operator to work on string keys

[Côme Chilliet]

Le Wed, 2 Dec 2020 17:45:47 +,
"G. P. B."  a écrit :

> The reason why this has been deferred is because of which semantics should
> be used for duplicate string keys.

['a' => 1, ...['a' => 2]] should be the same as ['a' => 1, 'a' => 2], I do not
see how any other way would be justifiable.

This means using array_merge semantic, as ['a' => 1, 'a' => 2] evaluates to
['a' => 2].

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

Re: [PHP-DEV] Re: PHP 8 is_file/is_dir input handling

[Côme Chilliet]

Le Tue, 1 Dec 2020 12:06:22 -0800,
Stanislav Malyshev  a écrit :

> But it's not incorrect. if is_file("abc\0") returns false, it's correct 
> - "abc\0" is not a correct filename, so I expect it to return false. It 
> does exactly what I need, so it's correct.

Hear hear. I think this is the best summary in this discussion.

is_file and is_dir should just return false on values which are not files and
dirs.

Can we please fix this for future PHP versions?
Does it need an RFC?

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

Re: [PHP-DEV] Preparing for PHP 8.0.0 GA

[Côme Chilliet]

Le Thu, 19 Nov 2020 08:50:04 -0600,
Sara Golemon  a écrit :

> Lastly, there are likely still gaps in the documentation of new features,
> so please take a moment away from code to make the manual better.

With the huge changes on parameter names in PHP-8, is there any easy automated
 process to fix documentation pages to match stubs?

Côme

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

Re: [PHP-DEV] Stubs in ext/ldap

[Côme Chilliet]

Le Thu, 17 Sep 2020 15:03:05 +0200,
"G. P. B."  a écrit :
> A lot of the documentation is not up to date and will needs to be updated
> after
> there has been a check of the argument names for consistency with other
> extensions in regards to named params, the stubs are the source of trust.  

I think a review of ext/ldap is needed then.

> UNKNOWN means that the default value cannot be specified due to some reason
> mostly the case for arguments passed by references or funcky function
> signature
> implementation which check the number of argument passed to the function.
>   
> > I would like to fix those conflicts.
> > Basically my questions are:
> > 1) What is the difference between s and S in zend_parse_parameters and how
> > do
> >  they behave for a NULL value?  
> 
> None in regards to userland as 's' is a char* followed by a size_t ad 'S'
> is a zend_string.
> As for all internal functions which are not nullable they will coerce null
> to the respective type
> so for a string argument null would become an empty string.  

So in the example of ldap_bind:
if (zend_parse_parameters(ZEND_NUM_ARGS(), "r|ss", ,
_bind_dn, _bind_dnlen, _bind_pw, _bind_pwlen) != SUCCESS)
{ RETURN_THROWS(); }

With ldap_bind($link, NULL), ldap_bind_dn is not NULL but an empty string?

> > 2) What would changing = UNKNOWN to = NULL impact?
> 
> Explicit support for nullable types in the C implementation
>   
> > 3) When a function like ldap_bind is called, is calling ldap_bind($link),
> > and
> >  ldap_bind($link, NULL) changing anything else than ZEND_NUM_ARGS?  
> 
> This relates to point 1 and 2 above, if there is no support for nullable
> types
> passing null can change the meaning of it.  

Then I think most of these needs to be changed to NULL with explicit support,
 as it was most likely what was intended. (the underlying C functions from
 libldap accepts NULL).
Also, there are tests like ldap_sasl_bind_basic.phpt which tests a NULL
 parameter.

What is the dead line for this kind of changes in ext/ldap regarding to PHP-8?

Côme

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

[PHP-DEV] Stubs in ext/ldap

[Côme Chilliet]

Hello,

After playing with phpstan and seeing their stubs for some LDAP functions were
 wrong, I noticed that documentation for LDAP functions and stubs in
 ext/ldap/ldap.stub.php differs.

Especially in a lot of functions, the documentation states "string $dn = NULL"
 but the stub states non-nullable string parameter. Also, the ldap.stub.php
 file contains a lot of "string $bind_rdn = UNKNOWN" in places where the
 documentations states = NULL. What does UNKOWN mean here?

I would like to fix those conflicts.
Basically my questions are:
1) What is the difference between s and S in zend_parse_parameters and how do
 they behave for a NULL value?
2) What would changing = UNKNOWN to = NULL impact?
3) When a function like ldap_bind is called, is calling ldap_bind($link), and
 ldap_bind($link, NULL) changing anything else than ZEND_NUM_ARGS?

Côme

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

Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values

[Côme Chilliet]

Le Wed, 2 Sep 2020 19:13:20 +0200,
Nikita Popov  a écrit :
> Just like the first time this was discussed, I don't think this RFC makes a
> sufficient case on why we need explicit syntax for this. Just ignoring the
> value is an existing pattern that works across all PHP versions:
> 
> foreach ($iterable as $key => $_) { ... }

I currently use foreach (array_keys($array) as $key) { ... }
 to avoid complains from code analysers on unused var, is it slower?
One obvious pro of having a dedicated syntax is not having to ask those
 questions to ourselves while coding.

> Iterating over just the keys is not a super common pattern and we already
> have a reasonable way to do it (that is imho just as clear, and actually
> more concise than the proposed "null" variant). The only potential
> advantage to a dedicated syntax that I see is that there could be iterators
> that can cheaply produce keys, but have expensive to produce values. That
> seems like an edge case of an edge case though, and is a situation where
> manually calling ->key() would be justifiable.

In our code base I thinks it is quite common.
grepping on "foreach (array_keys" gives me 51 cases, while grepping "foreach ("
 gives me 1153, so that’s 4% of our foreach uses.

Côme

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

Re: [PHP-DEV] Re: [VOTE] Shorter Attributes Syntax Change

[Côme Chilliet]

Le Thu, 20 Aug 2020 10:37:21 +0200,
Benjamin Eberlei  a écrit :

> On Thu, Aug 20, 2020 at 9:13 AM Côme Chilliet <
> come.chill...@fusiondirectory.org> wrote:  
> > Also, is it supposed to be updated at page load or at some time interval?
> > I see 15 votes on the RFC page for #[] and 14 on your page.
> >  
> 
> With 30 voters its likely one voted for the same thing twice accidentally
> and the vote is disqualified. Afaik Derick's script outputs that so the
> voter can be notified about their mistake.

Indeed, jwage voted for #[] as both 1st and 3rd choice.

Thanks for the explanation.

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

Re: [PHP-DEV] Re: [VOTE] Shorter Attributes Syntax Change

[Côme Chilliet]

Le Wed, 19 Aug 2020 21:11:29 +,
Theodore Brown  a écrit :
> In case anyone wants to view the in-progress STV vote results, I took
> the same script I made for the Shorter Attribute Syntax RFC and made
> it possible to run online here:
> 
> https://stv-results.theodorejb.me/php/?rfc=shorter_attribute_syntax_change
> 
> Note that at present it only processes the STV vote and ignores the
> primary 2/3 poll result, so keep that in mind.

Thank you, I was searching for something like this!

Is there any chance we can see the code? (mostly out of curiosity)

Also, is it supposed to be updated at page load or at some time interval?
I see 15 votes on the RFC page for #[] and 14 on your page.

Côme

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

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Côme Chilliet]

Le Thu, 13 Aug 2020 10:13:16 +0200,
Michał Marcin Brzuchalski  a écrit :

> I'm personally also disappointed with the fact that in your RFC under the
> primary
> vote question "Are you okay with re-voting on the attribute syntax for PHP
> 8.0?"
> removing features like grouping ability was hidden.

I still do not understand this point on grouping, how is using a syntax like @@
 or any that does not require grouping removing anything?

What is the grouping feature supposed to do?

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

Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2

[Côme Chilliet]

Le Thu, 6 Aug 2020 07:48:05 +0100 (BST),
Derick Rethans  a écrit :
> From the RFC:
> - No ending delimiter

As said before, it does have an ending delimiter when they are arguments since
 there is the parenthesis around them. When there are no arguments I don’t see
 the benefit of an ending delimiter, it’s easy to spot the end of the word.

> - Doesn't allow grouping

I do not understand this argument, what is the point of grouping for @@?
Does grouping mean anything special for other syntaxes, or is it just to save
 keystrokes? If it is just to get a more concise syntax when there are several
 attributes, the fact that @@ do not need grouping is a pro, not a con.

> - No forwards compat with PHP 7

But no BC break either, while #[] introduces BC break.

> - Not used ny another language

@ is used by a lot of other languages, and @@ is the closest we can get in PHP.

Côme

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

Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change

[Côme Chilliet]

Le Tue, 28 Jul 2020 17:57:34 +,
Theodore Brown  a écrit :

> Rust chose to use #[] even though it wasn't used by any other language.
> Does that make it a bad fit for Rust? No. But just because Rust uses
> a syntax also doesn't mean it's a good fit for PHP.

For those which like me do not know Rust, I checked and it appears that "#" is
 only used for attributes in Rust, and is not a comment starter.

So that explains why it makes sense for Rust to use this. But it still feels
 like a really bad idea to me to mix comment and code in PHP.

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

Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change

[Côme Chilliet]

Le Tue, 28 Jul 2020 09:46:38 -0500,
Joe Ferguson  a écrit :

> Hello Internals,
> 
> I've been working with Derick Rethans and others (thanks all!) on a Shorter
> Attribute Syntax Change RFC which outlines reasons why the "#[]" syntax
> would be preferred over the currently agreed upon "@@" syntax for Shorter
> Attribute Syntax.
> 
> An important part of the research that went into this proposal demonstrates
> how "@@" will make handling attributes more difficult for PHP_CodeSniffer
> (and similar tools) and shows how the alternative "#[]" syntax is more
> friendly for these tools.
> 
> You can find the RFC
> https://wiki.php.net/rfc/shorter_attribute_syntax_change and I'm happy to
> answer any questions as best I can.
> 

The text uses « instead of <<, it’s confusing.

It should be made clearer what #[ ] has over << >>, which does not cause any BC
 break.

Côme

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

Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?

[Côme Chilliet]

Le Thu, 23 Jul 2020 07:26:41 +0100,
Mark Randall  a écrit :

> What we do have, is a deep sense of unease that we collectively made the 
> wrong decision, based on, in part, incomplete information.

To be clear, is there anyone who voted for @@ and changed his mind based on new
 information?

I feel like all people wanting to re-vote or discard @@ syntax are the ones
 which voted against it.

Côme

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

Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?

[Côme Chilliet]

Le Wed, 22 Jul 2020 13:00:10 +0100 (BST),
Derick Rethans  a écrit :
> Please, let's do the sensible and use the Rusty #[...] syntax.

This syntax is the one I liked the less in the proposed choices, given # is
 used for comments.

Wouldn’t #[] cause more parsing issues than @@?

What would be the rule, it’d be illegal to start a comment content with '['?

Côme

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

Re: [PHP-DEV] [RFC][VOTE] debug_backtrace alternative as an array of StackFrame objects

[Côme Chilliet]

Le Tue, 21 Jul 2020 13:52:39 +0200,
Michał Marcin Brzuchalski  a écrit :
> Voting opened 2020-07-21 and closes 2020-08-04.
> 
> Link to the RFC https://wiki.php.net/rfc/stack-frame-class#vote

Hello,

Can people voting no explain their vote?
I did not see that much discussion against this prior to vote.

(I’m not convinced this should pass either, just wondering what the
pro/cons are here)

Côme

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

Re: [PHP-DEV] RFC proposal: Spread Operator for Array Destructuring Assignment

[Côme Chilliet]

Le Wed, 3 Jun 2020 11:46:00 +0200,
Nikita Popov  a écrit :
> To give a tl;dr of existing discussions on the topic:
> 
> $foobar = [2 => 2, 1 => 1, 0 => 0];
> [$foo, ...$bar] = $foobar;
> // What is the result?
> 
> Introducing this feature is primarily a matter of coming up with a
> satisfactory answer to the above question. (There is an existing
> constraint that $foo must be equal to 0 in this case, not 2.)

Well, I guess it should behave exactly the same as:

 $foobar = [2 => 2, 1 => 1, 0 => 0];
 [$foo, $foo2, $foo3] = $foobar;
 $bar = [$foo2, $foo3];

for consistency, no?

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

Re: [PHP-DEV] max_input_vars trigger detection

[Côme Chilliet]

Le Sun, 10 May 2020 13:34:12 +0100,
Craig Duncan  a écrit :
> Although not particularly elegant, and it does require you to
> reject  
> requests that hit but don't exceed the limit, I've used this approach
> before:
> 
> $max = ini_get("max_input_vars") - 1;
> $check = count($_REQUEST);
> if ($check > $max) {
>  throw new RequestException("Request is too large, only {$max}
> input variables are permitted");
> }

This is not even correct if I’m not mistaken, as max_input_vars applies
independently to GET, POST and COOKIE as I understand it. Here with
max_input_vars/2 in GET and POST your exception would throw while the
limit was not hit.

I know this is a corner case, but it’s just to illustrate it’s hard to
detect whether this limit was hit and it would be better in my opinion
to have a clean way in core.

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

Re: [PHP-DEV] Proposal For Return-If / Early Return / Guard Clause Syntax

[Côme Chilliet]

Le Sun, 10 May 2020 10:49:15 -0500,
Ralph Schindler  a écrit :
> The chosen syntax is:
> 
>return if ( if_expr ) [: optional_return_expression] ;
> 
> As a contrived example:
> 
>  function divide($dividend, $divisor = null) {
>  return if ($divisor === null || $divisor === 0);
> 
>  return $dividend / $divisor;
>  }

I do not understand the point, you are just reordering keywords, why is
that better than already correct code:

  function divide($dividend, $divisor = null) {
  if ($divisor === null || $divisor === 0) return;
 
  return $dividend / $divisor;
  }

I do not think an RFC and a special keyword are justified just to move
the word "return" from end to beginning of line.

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

Re: [PHP-DEV] [RFC] <> Attribute

[Côme Chilliet]

This is a really good proposal.

I did not participate in the attribute discussion/vote as I do not really 
understand what attributes are and what they are good for.
Having this kind of examples in core will help a lot, and is useful too (I do 
have functions with only a trigger_error of deprecation in my code already).

-- 
Côme Chilliet
FusionDirectory - https://www.fusiondirectory.org

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

[PHP-DEV] max_input_vars trigger detection

[Côme Chilliet]

Hello,

We’ve hit the max_input_vars limit some time ago, and at first I tried to 
detect this case, but I failed as there is no handy way to detect this 
situation.
In our case the application was complaining about CSRF token missing since the 
token was truncated, and you had to go see the logs to actually see the 
max_input_vars error.

For those not familiar with this ini setting, it defines a maximum number of 
input vars in either $_GET, $_POST or $_COOKIE. Additional variables are 
discarded. This is a good idea to avoid attacks sending lots of data, but the 
program has no way of knowing it’s working with a truncated $_POST, $_GET or 
$_COOKIE. 

Source: https://www.php.net/manual/en/info.configuration.php#ini.max-input-vars

In the end we reworked the application to prevent it from creating a form with 
more than 1000 inputs as it makes no sense and is not usable.

But still, it bugs me that there is no way to programmatically know that this 
limit was triggered.
With recent work into error handling a lot of what was warnings or fatal errors 
before is now easy to catch and treat properly. It would make sense to me that 
this also becomes something the program can react to.

So, would it be possible either to change the warning into some kind of 
catchable error (but I’m not sure which operation would trigger it? Maybe first 
access to $_POST (in case it’s POST which triggers the limit)?),
 or to add a flag, or a function to test whether this limit was triggered.
Like was_max_input_vars_reached($_POST) ? (or was_max_input_vars_reached(POST) 
with an enum)

-- 
Côme Chilliet
FusionDirectory - https://www.fusiondirectory.org

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

Re: [PHP-DEV] Renaming PhpAttribute to Attribute

[Côme Chilliet]

Le mercredi 29 avril 2020, 14:58:02 CEST Nikita Popov a écrit :
> On Wed, Apr 29, 2020 at 2:51 PM Côme Chilliet <
> come.chill...@fusiondirectory.org> wrote:
> > Le mardi 28 avril 2020, 18:59:22 CEST Benas IML a écrit :
> > > Could you provide any examples as to where '\Attribute' is being used in
> > the
> > > wild? I haven't seen a single project that has an Attribute class and
> > uses the
> > > global namespace.
> >
> > We do use an Attribute class in FusionDirectory:
> > https://gitlab.fusiondirectory.org/fusiondirectory/fd/-/blob/1.4-dev/include/simpleplugin/class_Attribute.inc
> >
> > I’d expect a lot of projects to have an Attribute class, since there are
> > things named attributes in lots of contexts.
> 
> Great! You have discovered a nice opportunity to finally move your code
> into the FusionDirectory namespace.
> 
> PHP reserves (de facto if not de jure) the global namespace for it's own
> purposes. If you want to place classes in the global namespace, without
> prefixing them, that's fine, but please don't complain if there are clashes.

This is a bit harsh, I did not complain, I provided an example of project to 
someone who wrote «Could you provide any examples».
I can, so I did.

-- 
Côme Chilliet
FusionDirectory - https://www.fusiondirectory.org

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

Re: [PHP-DEV] Renaming PhpAttribute to Attribute

[Côme Chilliet]

Le mardi 28 avril 2020, 18:59:22 CEST Benas IML a écrit :
> Could you provide any examples as to where '\Attribute' is being used in the
> wild? I haven't seen a single project that has an Attribute class and uses the
> global namespace.

We do use an Attribute class in FusionDirectory: 
https://gitlab.fusiondirectory.org/fusiondirectory/fd/-/blob/1.4-dev/include/simpleplugin/class_Attribute.inc

I’d expect a lot of projects to have an Attribute class, since there are things 
named attributes in lots of contexts.

-- 
Côme Chilliet
FusionDirectory - https://www.fusiondirectory.org

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

Re: [PHP-DEV] [RFC] Mixed type

[Côme Chilliet]

Le lundi 20 avril 2020, 09:15:24 CEST Sara Golemon a écrit :
> use mixed = null|bool|int|float|string|array|object|resource;
> use scalar = null|bool|int|float|string;

I’m wondering if null should maybe be left out of these, since ?mixed and 
?scalar can be used for this?

-- 
Côme Chilliet
FusionDirectory - https://www.fusiondirectory.org

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

Re: [PHP-DEV] [RFC] [EPILOGUE] Server-Side Request and Response Objects (v2)

[Côme Chilliet]

Le mercredi 8 avril 2020, 07:35:10 CEST Paul M. Jones a écrit :
> ## Lessons Learned
> 
> ### Userland Functionality
> 
> The initial impression is that there is a strong desire for work that *can* 
> be done in userland to *stay* in userland. However, that impression conflicts 
> with the recent acceptance of `str_contains()`, which is very easily done in 
> userland.
> 
> **Lesson:** Of functionality that can be accomplished in userland, only 
> trivial/simple functionality is acceptable.

My take on that is more that functionality in core needs to be «perfect», or at 
least near unanimous. And of course it’s way easier to find a solution which 
pleases everyone when it’s for something quite simple.
I do think OO interface for request/response in core is something that could 
pass, but it would need to be more in line with what people want/expect.

> ### Userland Ecosystem
> 
> There was somewhat less concern for "the ecosystem," but it too was prevalent 
> in the discussion.
> 
> **Lesson:** Perceived challenges to popular userland projects are going to be 
> met with strong resistance by their existing stakeholders, even when an RFC 
> is explicitly not a challenge to them.

You clearly disagree on this with most participants in the discussion, but 
saying «this RFC is not a challenge» is not enough to make it true, there was a 
clear overlap of feature between your RFC and existing userland projects so it 
made sense to compare them.

-- 
Côme Chilliet
FusionDirectory - https://www.fusiondirectory.org

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

Re: [PHP-DEV] Resurrecting named parameters

[Côme Chilliet]

Le mardi 7 avril 2020, 14:44:38 CEST Nikita Popov a écrit :
> The larger problem is that internal functions don't have a well-defined
> concept of parameter default value. Parameter defaults are implicit in C
> code, and sometimes based on argument count checks. When named parameters
> are involved, one generally cannot assume that if a later (optional)
> parameter is passed, all earlier (optional) parameters are passed as well.
> 
> While it is possible (but rather challenging) to make things work mostly
> transparently with current ZPP, some functions do need to adjusted to
> support named parameters, and may cause misbehavior/crashes if they are
> not. As a rule of thumb, functions that make non-trivial use of
> ZEND_NUM_ARGS() are affected. This is something we can address for
> functions in bundled extensions, but may also affect 3rd-party extensions.
> 
> I think that ideally, we'd deal with internal functions the same way we do
> for userland functions, by relying on default values that are part of the
> function declaration. As part of the PHP stub work, we now have information
> on default values in stub files, but this information is currently not
> available to the engine.

This is a more general problem with internal functions which bugs me a lot.
They can behave in a different way when not providing an attribute and when 
providing the default value.

We should aim to make them behave exactly as a userland function with the same 
stub, no?

-- 
Côme Chilliet
FusionDirectory - https://www.fusiondirectory.org

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

Re: [PHP-DEV] [VOTE] Object-based token_get_all() alternative

[Côme Chilliet]

Le mercredi 11 mars 2020, 10:59:19 CET Larry Garfield a écrit :
> I forget who it was but someone on the list a while back offered a heuristic 
> of "__toString should be used iff there is one and only one logical string 
> representation of a value, because the value is conceptually just a string 
> with extra metadata on it".
> 
> That sounds like a really solid heuristic to me.  In this case, I think yes, 
> ->text is the only reasonable thing to produce for __toString().  

Yes that was my reasoning, a token is essentially a substring, so I was 
expecting __toString to reflect this and allow me to use it as a string.

-- 
Côme Chilliet
FusionDirectory - https://www.fusiondirectory.org

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

Re: [PHP-DEV] [VOTE] Object-based token_get_all() alternative

[Côme Chilliet]

Le mardi 10 mars 2020, 15:53:41 CET Nikita Popov a écrit :
> Would __toString() return $token->text? I'm not strictly opposed to this,
> but I'd be hard pressed to think of a situation where I would prefer
> writing (string) $token over $token->text. Generally, the less magic the
> better :)

My idea was that since tokens are parsed from a string it should be easy to 
write a string back with them.
I do not have an obvious usecase but the idea is doing stuff like

if ($token.is('function')) {
echo "public $token";
} else {
echo $token;
}

Am I right to assume that with __toString the same as ->text we’d have 
implode('', PhpToken::getAll($code)) == $code ?

This would allow:
$tokens = PhpToken::getAll($code);
// Modifications on $tokens
$code = implode('', $tokens);

-- 
Côme Chilliet
FusionDirectory - https://www.fusiondirectory.org

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

Re: [PHP-DEV] [VOTE] Object-based token_get_all() alternative

[Côme Chilliet]

Hello,

I know I’m late, but shouldn't these tokens have a __toString() method? 
It’s not listed in rejected features.

-- 
Côme Chilliet
FusionDirectory - https://www.fusiondirectory.org

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

Re: [PHP-DEV] Require non-absolute trait method references to be unambiguous

[Côme Chilliet]

Le mardi 3 mars 2020, 15:11:27 CET Nikita Popov a écrit :
> As the error message indicates, the ambiguity is resolved by writing
> 
> use T1, T2 {
> T1::func as renamedFunc;
> // or
> T2::func as renamedFunc;
> }
> 
> depending on which of those you actually meant.

Is that valid in PHP-7 as well?

-- 
Côme Chilliet
FusionDirectory - https://www.fusiondirectory.org

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

Re: [PHP-DEV] Allow null variables to be decremented

[Côme Chilliet]

Le mercredi 19 février 2020, 15:59:24 CET Christian Schneider a écrit :
> Am 19.02.2020 um 15:52 schrieb Côme Chilliet 
> :
> > Is there any reason the engine is not running the same code or even 
> > compiling to the same opcodes $a++ and $a+=1?
> > If it should never differ, why is it not the same operation?
> 
> $a++ is magic, see example #1 at 
> https://www.php.net/manual/en/language.operators.increment.php 
> 
> And no, this should not be changed as it would be a major BC.

Right, $a+=1 is the same as ++$a, not $a++, my bad, I forgot about this.

Is ++$a behaving differently than $a++ for NULL/FALSE/TRUE?

-- 
Côme Chilliet
FusionDirectory - https://www.fusiondirectory.org

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

Re: [PHP-DEV] Allow null variables to be decremented

[Côme Chilliet]

Le mardi 18 février 2020, 20:27:37 CET Rowan Tommins a écrit :
> With booleans, there is at least a consistency between those two 
> operators, even though it's consistently weird. There's definitely a 
> strong case for making them match +=1 and -=1 though.

Is there any reason the engine is not running the same code or even compiling 
to the same opcodes $a++ and $a+=1?
If it should never differ, why is it not the same operation?

-- 
Côme Chilliet
FusionDirectory - https://www.fusiondirectory.org

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

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

[Côme Chilliet]

Le mardi 18 février 2020, 07:33:37 CET Paul M. Jones a écrit :
> ... the output would be "b\n". As you say, setContent() replaces whatever 
> content is already in the ServerResponse. While the comparison for a single 
> echo is accurate, the comparison for multiple echoes would be:
> 
> $content = "a\n";
> $content .= "b\n";
> $response->setContent($content);
> $responseSender->send($content);
> 
> Does that help to clarify?

Yes, but to me that means we also need an addContent method.
Otherwise people will have to carry a global $content along side $response, or 
use setContent(getContent().$additionalContent).

-- 
Côme Chilliet
FusionDirectory - https://www.fusiondirectory.org

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

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

[Côme Chilliet]

Le jeudi 13 février 2020, 09:16:49 CET Paul M. Jones a écrit :
> Yeah, naming is one of the hard problems. I considered $query as an 
> alternative property name for $get, but in the end, the `$_GET => $get` 
> symmetry was too great to ignore. If others here feel that $query is a better 
> name for `$_GET` than $get, I will submit to consensus on that point.

query is definitely better than get.

Regarding post, I’m fine with body, parsedBody and input.

I get the idea of input to mimic php://input, but if I understand things 
correctly, php://input is raw body, while $request->post is parsed body, so 
naming them alike might actually cause confusion?

> > Given 'echo $content; => $response->setContent($content);', shouldn't
> > this rather be something like `addContent()`?
> 
> That looks like poor describing on my part in the RFC. It is more true to say 
> that these are equivalent:
> 
> echo $content;
> 
> // =>
> 
> $response->setContent($content);
> $responseSender->send($response);
> 
> I will try to make that more apparent in the RFC.

I still do not understand this.
echo adds content to the response, it does not replace it.
So the equivalent function should be $response->addContent.

I would expect $response->setContent to replace the content.

Can you explicit behavior for this:

  $response->setContent("a\n");
  $response->setContent("b\n");
  $responseSender->send($response);

Compared to

  echo "a\n";
  echo "b\n";

-- 
Côme Chilliet
FusionDirectory - https://www.fusiondirectory.org

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

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

[Côme Chilliet]

Le mercredi 12 février 2020, 19:20:56 CET Niklas Keller a écrit :
> Naming
> 
> I think we shouldn't take over the naming of the super globals, e.g.
> $_GET really contains the query parameters and has nothing to do with
> GET or POST, so $request->getQueryParameter(...) would be a better
> name.

I think this remark is really on point.
GET and POST are HTTP methods and not ways of passing data. You can have query 
parameters on any request, and you can have POST data with a lot of other HTTP 
methods, as is commonly used in REST APIs.

I do not like the name getQueryParameter at first sight, but I do not like 
get() and post() for getting values from $_GET and $_POST.
I would expect a method named post to actually post something, not just get a 
value.

-- 
Côme Chilliet
FusionDirectory - https://www.fusiondirectory.org

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

Re: [PHP-DEV] GitHub RFC workflow

[Côme Chilliet]

Le samedi 2 novembre 2019, 19:40:56 CET Joe Watkins a écrit :
> I would like to question the reasoning behind wanting to "own" the RFC
> content: We don't require any such thing for any other kind of PR although
> we say we require a patch on bugsnet, we actually don't require it. So, I
> have a hard time telling the difference between a PR for an RFC and a PR
> for a bugfix or enhancement.
> 
> Can anyone tell the difference ?

Whether there is a difference or not, «we already use too much github» is not a 
reasonable argument for «let’s use more github».
It would of course be better if the PRs were not done through github, but as 
far as I know this is not mandatory and people are allowed to do PR through 
other systems.

I’m still strongly against using github for RFCs, and missed most of the 
discussion on union types because it was there and hard to follow (things are 
not chronological, I can’t know easily if there are new comments and which ones 
are, usability is not the reason I’m against github but it was also bad).

-- 
Côme Chilliet
FusionDirectory - https://www.fusiondirectory.org

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

Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)

[Côme Chilliet]

Le vendredi 6 septembre 2019, 16:47:52 CEST Nikita Popov a écrit :
>  * GitHub would not be the exclusive venue for RFC discussion. All RFCs are
> still announced on internals and the top-level discussion can and should
> still happen here.

My remark on the mailing list regarding string|true was unanswered and I had to 
go over to github to see that the concern was discussed there.
This is the kind of problems splitting the discussion will cause, people will 
have to check both places or miss things.

Regarding the github PR as a practical point of view, I find it hard to check 
if there are new messages since last time I visited the page. Is there any way 
to browse messages by time? (backwards ideally).

Côme

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

Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)

[Côme Chilliet]

Le jeudi 5 septembre 2019, 13:07:28 CEST Dan Ackroyd a écrit :
> On Thu, 5 Sep 2019 at 12:27, Côme Chilliet  wrote:
> >
> >  PHP have no control over github, and cannot know how it will evolve.
> >
> >  (they can change the platform tomorrow and internal won’t be able to do 
> > anything about it).
> 
> Those are hypothetically problems. But they do not appear to be
> currently problems.

The fact that PHP has no control over github is current, this is not 
hypothetical.

> And in case anyone says "some people might not be able to comment on
> Github" the same is true for our email lists. The signup process was
> apparently broken for ages, and I've seen multiple people ask for how
> to persuade the system to accept their messages. Which probably means
> there are more people who never contributed because they couldn't get
> past that first barrier.

It’s not the same when the project can act to fix it and when the project is 
powerless.
If github blocks someone from commenting we cannot do anything about it.

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

Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)

[Côme Chilliet]

Le jeudi 5 septembre 2019, 12:50:48 CEST Joe Watkins a écrit :
> > Because the PHP project should avoid depending on a privately owned 
> > centralized service for its technical discussions
> 
> This is obviously your opinion, but you haven't actually told us why this
> is the case, and it's not at all obvious.

I thought it was obvious, sorry.
So, the problem is PHP have no control over github, and cannot know how it will 
evolve.

GAFAM organizations have closed people accounts before, sometimes without 
giving reasons.
I think PHP project should not let other organisations choose who can or cannot 
participate in PHP development.

> > should not encourage (some would say force) people to use such platforms.
> 
> In any case it's not a choice for the contributor, internals chooses the
> medium and the contributor has to use it. Whether we force them to use a
> mailing list from last century or something from this century makes no
> difference with regard to choice for the contributor.

With a mailing list the contributor can choose its email server and email 
client. He does not have to agree to term of service of a third party.
https://tosdr.org/#github
With github, internal chooses to delegate to github, and github (currently 
microsoft) chooses who can take part in the discussion and how the discussion 
works. (they can change the platform tomorrow and internal won’t be able to do 
anything about it).

Côme

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

Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)

[Côme Chilliet]

Le jeudi 5 septembre 2019, 12:04:55 CEST Brent a écrit :
> > Huge "no" from me on using github for discussing RFCs.
> 
> Care to elaborate why? The majority seems to like it. Though I am also 
> curious about Nikita's experience with it, as he is the one having to process 
> the feedback.

Because the PHP project should avoid depending on a privately owned centralized 
service for its technical discussions, and should not encourage (some would say 
force) people to use such platforms.

PHP is already on github but it’s only a mirror, the main git repository is at 
git.php.net .

Côme

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

Re: [PHP-DEV] Union Type (singular) straw man proposal

[Côme Chilliet]

Why does the class Number in the example has a $number property and use 
$this->number->value() rather than $this->value() ?

What is the difference between its getNumber method and its value method?

Is $this->number and $this->number->number pointing the same object or is 
$this->number->number NULL?

This example is really confusing me more than anything else.

The "function showNumber" example is using $this->number instead of $number I 
think.

All in all I do not understand the benefits of this approach compared to 
Nikita’s RFC.
What does this allow you to do that you cannot do without?

Côme

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

Re: [PHP-DEV] [RFC] Union Types v2

[Côme Chilliet]

Le mercredi 4 septembre 2019, 10:26:09 CEST Nikita Popov a écrit :
> As an experiment, I'm submitting this RFC as a GitHub pull request, to
> evaluate whether this might be a better medium for RFC proposals in the
> future. It would be great if we could keep the discussion to the GitHub
> pull request for the purpose of this experiment (keep in mind that you can
> also create comments on specific lines in the proposal, not just the
> overall discussion thread!) Of course, you can also reply to this mail
> instead. The final vote will be held in the wiki as usual.

Huge "no" from me on using github for discussing RFCs.

Huge "yes" on the RFC content.

>  * Only supports "false" as a pseudo-type, not "true".

I think it would make sense to support true as well as I’ve seen a lot of cases 
of functions returning either an error string or TRUE on success.
So that would be string|true.

Côme

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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Côme Chilliet]

Le mercredi 7 août 2019, 15:57:02 CEST Chase Peeler a écrit :
> Pretty much everyone (if not actually
> everyone) that is against this RFC has stated that they don't actually use
> short tags, and do not advocate that anyone else use them either.

This is what bugs me, the counter argument page from Zeev states «I never use 
short tags in any PHP code that I write, and as far as I recall - I never have. 
»,
 and at the same time «put hundreds of thousands of people through additional 
pain when upgrading.»

Is there any data that support the theory that hundreds of thousands of people 
use short tags?

Did anyone in this discussion stated that he was using them?

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

Re: [PHP-DEV] Handling of null arguments to internal functions

[Côme Chilliet]

I’m not sure if this is exactly the same topic, but one problem I have with how 
internal functions are handling arguments is how the absence of an optional 
argument is treated.

I have stumbled across functions documented as functionname($arg1, $arg2 = 
NULL) which behaves differently when called as functionname('something') and 
functionname('something', NULL).
A lot of places in the documentation state "if omitted" about an argument.

This is a big problem when several arguments are optional and you just want to 
provide a value for the last one. You cannot know if giving the default value 
for the ones in between will affect the behavior.

Shouldn’t the argument parsing system treat absence the same as the default 
value?
This is what happens for userland functions.

Côme

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

Re: [PHP-DEV] Re: [RFC] Numeric Literal Separator

[Côme Chilliet]

Le mercredi 29 mai 2019, 10:39:17 CEST Markus Fischer a écrit :
> My understanding from the RFC is that that the grouping is not relevant, 
> the `_` is stripped regardless.
> 
> Am I wrong?

No you’re not, the RFC allows grouping as the coder wants.

Which is why I think it may cause problems because the way the coder wants to 
group digits and the way easier for me to read is not always the same.
As Christoph M. Becker states there are already problems like this with choice 
of names for variables and code style and such, but until now numbers were a 
safe place that always looks the same.

If people want to see big numbers broke up in groups of 3 I would expect their 
IDE to do this on numbers for them.

But I do get the point of the RFC for hexa and bit masks.

Côme

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

Re: [PHP-DEV] Re: [RFC] Numeric Literal Separator

[Côme Chilliet]

What bugs me with this RFC is that it seems to be mainly intended for grouping 
digits by 3, which from what I understand is cultural.
At least some asian languages have a concept of 
https://en.wikipedia.org/wiki/Myriad and group them by 4, at least from the 
language point of view.
It does seem when writing as numbers they still group by 3, but it seems other 
usages exists:
https://japantoday.com/category/features/lifestyle/10-000-or-1--japanese-schools-are-starting-to-move-commas-on-big-numbers-but-why

Anyway, just wanted to point out that grouping digit may not be completely 
universal.
I will not vote no on the RFC, most likely I won’t vote. But I think I will not 
use this in my code.

Côme

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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

[Côme Chilliet]

Le jeudi 25 avril 2019, 00:11:42 CEST Thomas Hruska a écrit :
> So I built a tool that meets the above minimum criteria and have already 
> run it against a fairly extensive codebase (and have shared the tool 
> with a few concerned folks - you've already seen its output here on-list):
> 
> https://github.com/cubiclesoft/php-short-open-tag-finder/

«// (C) 2019 CubicleSoft.  All Rights Reserved.» does not meet my minimum 
criteria.

> Tools that just walk down a directory tree and bulk 
> modify by default, […] should all be rejected from 
> consideration.  

I do not understand why you have a problem with this, the rest of your email 
seems to suggest you are using git.
Just run the tool and then look at the diff before committing anything.

This makes *way* more sense than having to manually review each change one by 
one.

Côme

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

Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2

[Côme Chilliet]

Le vendredi 5 avril 2019, 11:00:59 CEST Michał Brzuchalski a écrit :
> So we're talking about providing incomplete feature now, right?

As I understand it, the point is to make unpacking available to arrays, to be 
consistent with function calls.

// This is already supported
$result = someFunction($a, $b, ...$array);
$result = new someClass($a, $b, ...$array);

// This is not
$result = array($a, $b, ...$array);

So when building an object I can unpack, but not when building an array, why?

So the feature is designed to work the same way as for function parameters, 
which is why string keys are not supported, because they are not supported by 
the "..." operator for functions.

In the end, I see that as making a feature more complete, as the "..." operator 
which only supported functions will now support array constructors as well.

Côme

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

Re: [PHP-DEV] PHP_FLOAT_MIN is positive

[Côme Chilliet]

Le mercredi 3 avril 2019, 13:47:55 CEST Joe Watkins a écrit :
> 2.2250738585072E-308
> 
> This is negative.
> 
> Cheers
> Joe

No it’s not.
It’s positive and close to 0.

Côme

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

Re: [PHP-DEV] [RFC] Deprecate PHP's short open tags

[Côme Chilliet]

Le lundi 25 mars 2019, 08:45:22 CET Thomas Hruska a écrit :
> If this moves forward, I, and many others, will demand a formal, fully 
> supported utility for locating and automatically transforming all usages 
> of short open tags on the system.  That is, a scanner to locate every 
> line of code that uses them with options to change the code 
> automatically.  

You can use the fixer "full_opening_tag" of php-cs-fixer:
https://cs.symfony.com/

There is also "no_short_echo_tag" if you want to replace "http://www.php.net/unsub.php

Re: [PHP-DEV] Variadic is_*() functions

[Côme Chilliet]

Le lundi 11 février 2019, 08:59:17 CET Levi Morrison a écrit :
> My position is the same: pushing the variadic behavior into the
> functions means that each function needs to pick `||` or `&&`
> behavior, both of which are useful. I would rather see more
> descriptive function names, such as `all_of` or `any_of`:
> 
> if (!all_of('is_numeric', [$input['example1'],
> $input['example2']])) {/*...*/}

My first thought was that this must already exists under another name, but it 
seems that none of array_map, array_walk or array_reduce allows to do that 
easily.
(That is, in a more readable way than the boolean operator string, otherwise 
it’s useless)

Côme

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

Re: [PHP-DEV] Don't silence fatal errors

[Côme Chilliet]

Le dimanche 10 février 2019, 09:34:16 CET Pierre Joye a écrit :
> However I think you are right as well in your other replies. While I wrote
> @ free code since years and I rarely see some in modern code, removing it
> may bring some BC issues that could delay 8 adoptions.

Not sure where in this thread is the right place to answer, but I felt like I 
had to report that the php-ldap module triggers warning for about all errors 
and is almost impossible to use without @ because of this.
I did not attempt at fixing this for now since it would be huge BC breaks and 
if we’re going for BC breaks a lot of the ldap module API could be redesigned.

The other case where error handling through warning is a big problem is fopen, 
for which I usually use the same kind of wrapper (setting error handler) as 
posted by someone else.

Côme

--
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)

[Côme Chilliet]

Le mardi 5 février 2019, 11:53:01 CET Zeev Suraski a écrit :
> We'll have to agree to disagree on this one.  I would say that the way
> virtually every other major Open Source project serves as a fairly good
> proof point for my position.  In fact, even with the new eligible voting
> criteria, we'd be well ahead of most other major OS projects in terms of
> the number of people included in the process with full equal voting rights.

I do not understand what this proves.

«No other project is doing that» is not a strong enough argument towards not 
doing it.
What is the problem you are actually trying to solve? That some RFCs are not 
passing?

Côme

--
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)

[Côme Chilliet]

Le mardi 5 février 2019, 02:38:50 CET Stanislav Malyshev a écrit :
> Hi!

Hi!

> Do you imagine Linus
> asking a vote of all Linux users about how to implement a kernel driver
> and implementing it only in a way that majority of Linux users approves?

Not sure that would be so bad. 
At least until it blocks everything and becomes a problem, but what I do not 
understand is that changing the RFC voters pool idea do not seem come from a 
problem with it, just some «These people are not writing C code, they should 
not vote» thinking.

> Because whoever makes the thing defines how the thing is made (of
> course, it takes more to make PHP than pure C coding, so I am bundling
> all contributors to the project - however widely defined - together). If
> you are to build a house, I am not going to tell you how to do it. It's
> your house, you build it however you want it - even if you might later
> invite me to visit. If I think the house is badly built, I may refuse to
> come, and criticize you, but I won't claim the power to tell you how to
> do it.

This is where we disagree, PHP devs are not building a house for themselves, 
they are building it for other people.

> Have a say, as in providing feedback and advice - sure, and they do.
> Having decisive voice, overriding the voice of people who actually
> implement it, in their own free time, and then give it away for free - no.

If I use my free time to make the language worse, that is not a good thing just 
because I did some work for free.

> > You make it like it’s a gift for people to be able to vote on PHP
> > RFCs while I feel like it’s good for PHP to have people voting its
> > RFCs.
> 
> There's no abstract "PHP" that it'd be good for beyond people who
> actually develop it. And I don't see how it'd be good for people who
> develop it to give control over how to develop it to people that don't.

I disagree here, PHP is supposed to be good to its community, not only its core 
developers.

> > One last point: Having non-core developers voting puts a higher bar
> > on RFC redacting quality: The author needs to explain his feature
> > well enough so that people without deep internal knowledge get it.
> 
> I don't see how the voting process prevents people that didn't get it
> from voting (either way). In a democracy, people do it all the time ;)
> So this is really not a solid argument for your point.

You may always have some random or misinformed vote but I do think you will get 
more vote if you successfully explains how your feature improve the situation.
When I do not understand at all what it’s about I usually don’t vote (for PHP 
RFCs I mean).

Côme


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

Re: [PHP-DEV] [VOTE] Making stdClass iterable

[Côme Chilliet]

Hello,

What is the usecase for this?

The RFC does not explain what it would be useful for.
json_decode already provides an option for getting arrays instead of objects.

All in all the RFC does not provide enough information. As I understand it if 
stdClass is Traversable then all objects are, no?

Côme

--
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)

[Côme Chilliet]

Le mardi 5 février 2019, 10:36:48 CET Zeev Suraski a écrit :
> Regardless of what you did, actually obtaining full voting rights
> meant you had to ask for a VCS account, and have a reasonably good
> explanation on why you need one - enough to convince one of the folks
> with admin rights on master.php.net to click the 'Accept' button.
> That's all.  Immediately, one has identical rights to someone who may
> have been spending years of their time on PHP, in a one way ticket.

To me that is the purpose of voting, what you’re saying is like complaining 
that in a democracy old people with experience has the same voting power than 
young ones.
I feel for votes to make sense you need a lot of people voting, a vote between 
the 10 core developers does not make a lot of sense, and could well be replaced 
by a discussion on a mailing list.

I’m also not sure why one would need to be coding PHP itself to be able to vote 
its direction, I feel it’s sane that people using it have a say in it. 
I know you (or someone else) explained having a say in it does not necessarily 
means having voting power, but I feel it does.
I’m not sure without voting power I would follow closely RFCs as I do now.
So I think this is where my main disagreement with these criteria is: I like 
that people interested in PHP can get access to voting where it goes.

> As I mentioned above, the criteria is open for debate.  From my POV
> though, having such a criteria and implementing it - even if it's 7.5
> years too late - is a must.
> I agree that a commit count isn't a good criteria on its own, but as
> mentioned above - I think it adds value as an added bar for the
> already-low 500 line count.
> I consider both criteria as fairly low bars for full voting powers on
> one of the most popular open source projects in the world.

You make it like it’s a gift for people to be able to vote on PHP RFCs while I 
feel like it’s good for PHP to have people voting its RFCs.

> Also note that the 'Grandfathering' period aims at providing a
> reasonable transition for those who are borderline qualified to vote,
> and gives them a full year to clear the bar to retain their full
> voting rights.

This is exactly the problem with such criteria: It will push people to do 
things just to get the criteria, like fix typos in comments or split features 
in several commits to make the count.
Voting system criteria should not influence the way we write the code.

One last point: Having non-core developers voting puts a higher bar on RFC 
redacting quality: The author needs to explain his feature well enough so that 
people without deep internal knowledge get it. This is a good thing.

Côme

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

Re: [PHP-DEV] New website for the PHP project

[Côme Chilliet]

Le lundi 4 février 2019, 14:44:31 CET Rowan Collins a écrit :
> In general, though, I quite like the current site design, and would much
> rather effort was spent iteratively improving it, rather than throwing it
> away and implementing a new set of bugs.
> 
> My personal annoyance is the search result page; specifically, that the
> "Full website search" link appears in the sidebar like it's an
> afterthought, rather than prominently with the search results, or as a
> separate results tab or something.

I agree, I like the current website and design and would see much more value in 
an attempt at fixing small problems one by one rather than trying to redo the 
whole thing at once.

Change the pages organization a bit would improve things, but the design do not 
need to change.

For example I hate how this page https://php.net/support has the "Table of 
Contents" on the right while this one https://php.net/get-involved.php has 
unique information in the same place that you overlook the first time you read 
the page.
When I tried to get involved in PHP the first time, I got to 
https://php.net/get-involved.php, read the "Development of the PHP source" 
section and was like «Hum, ok, but where is the source? Why aren’t there any 
links here?». The stuff in the right column should really be in the middle and 
replaced with a Table of contents for consistency IMO.

Côme

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

Re: [PHP-DEV] Re: 7.3 features in announcement

[Côme Chilliet]

Le mardi 4 décembre 2018, 16:35:14 CET Christoph M. Becker a écrit :
> PHP-7.3 is the main branch for 7.3; please commit relevant changes to
> UPGRADING there (and merge up to master).  PHP-7.3.0 is the release
> branch, which usually is maintained by the RMs only, who cherry-pick
> important commits from PHP-7.3 into it.

I pushed to PHP-7.3 but could not merge into master due to a Karma problem:

> remote: Welcome mcmic.
> remote: You have insufficient Karma!
> remote: I'm sorry, I cannot allow you to write to
> remote: php-src.git/
> remote: Have a nice day.
> To git.php.net:/php-src.git
>  ! [remote rejected]   master -> master (pre-receive hook declined)

Côme

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

Re: [PHP-DEV] Re: 7.3 features in announcement

[Côme Chilliet]

Le lundi 3 décembre 2018, 12:37:45 CET Christoph M. Becker a écrit :
> Thanks!  Indeed, PR #2640 looks like a considerable improvement.  Please
> add a respective entry in UPGRADING (either self-explaining, or linking
> to another document).

I started https://secure.php.net/manual/en/ldap.controls.php and adding 
documentation for the new functions as well (The online version is outdated 
last version is in the svn).
It’s not clear for me in which branch I should edit UPGRADING, it seems master 
is now 7.4, should I edit in PHP-7.3 or PHP-7.3.0? What’s the difference?

Also what is the difference between UPGRADING and NEWS?

Regarding the online documentation, it seems http://doc.php.net/tutorial/ is 
down as well as http://docs.php.net/

Côme

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

Re: [PHP-DEV] Re: 7.3 features in announcement

[Côme Chilliet]

Le dimanche 2 décembre 2018, 23:50:54 CET Christoph M. Becker a écrit :
> I'm likely missing other important changes, and may overestimate some of
> those I've mentionened above.  I'm looking forward to suggestions!

It would be good if LDAP controls support in php-ldap is advertised, as it also 
shows the module is maintained again.

Sadly I do not have a good link to give for this, I’m gonna try and fill the 
documentation about this so that it can be linked to.

Côme

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

Re: [PHP-DEV] [RFC] Spread Operator in Array Expression

[Côme Chilliet]

Le mercredi 21 novembre 2018, 22:46:42 CET Levi Morrison a écrit :
> I think we have `+` and `array_merge` already. What we *don't* have is
> something that concatenates solely with values and ignores keys, at
> least not in a single step. I think `...` can be that operator,
> precisely because this is what it does for function calls as well.

For function calls you cannot use it with non-integer keys, the behavior is yet 
to be defined.

So if later there are named arguments and ... behaves like array_merge on 
parameters it would be weird to have it behave an other way on arrays.

I would make the ... operator behave the same in all places, so in array it 
should refuse string key as it does for function calls, for the time being.

Côme

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

Re: [PHP-DEV] [VOTE] array_key_first(), array_key_last(), array_value_first(), array_value_last()

[Côme Chilliet]

Le vendredi 13 juillet 2018, 16:48:29 CEST Levi Morrison a écrit :
> Below is a proof-of-concept for the `array_offset` function [mentioned
> by Nicolas Grekas][2] (which by the way, neither the RFC author nor
> anyone else responded to this suggestion) that is simply a convenience
> wrapper over `array_slice`:
> 
> function array_offset(array $input, int $offset): ?array {
> $slice = array_slice($input, $offset, 1, true);
> return count($slice) ? $slice : null;
> }
> 
> $assoc = ['one' => 1, 'two' => 2, 'three' => 3];
> $packd = range(1, 4);
> 
> var_dump(array_offset($assoc, -1));
> var_dump(array_offset($packd, -1));
> 
> var_dump(array_offset($assoc, 0));
> var_dump(array_offset($packd, 0));
> 
> Of course, the `array_slice` function can be used to build all of the
> functions described in the RFC, as well.

How would you do that, since array_slice still gives you an associative array 
as a result?
array_values(array_slice($array, -1, 1, true))[0] is way less readable than 
array_last_value($array), and the question «how efficient is that and how many 
array copies are made?» becomes complicated to answer for non-initiated.
While with a native function you expect it to be as efficient as possible to do 
what you ask it.
(And as you state in your other mail in the end this array_slice solution is 
not as efficient as you expected)

I would have been fine with array_key($array, $offset=0) and 
array_value($array, $offset=0) instead of the 4 functions from the RFC to be 
able to use any offset.

Côme

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

Re: [PHP-DEV] [VOTE] array_key_first(), array_key_last(), array_value_first(),array_value_last()

[Côme Chilliet]

Le jeudi 12 juillet 2018, 01:04:36 CEST Andrea Faulds a écrit :
> Hmm. Returning null with no warning makes perfect sense for keys, since 
> null is not a valid key so there's no ambiguity, but for values it seems 
> problematic. On that ground I've decided to change my vote to No for the 
> value functions, but keep the vote for Yes for the key functions. 
> Someone who wants such behaviour could always do 
> ($array[array_key_last($array)] ?? null), I guess.

You cannot do that easily if the array is returned by a function.
function()[array_key_last(function())] would call the function twice.

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

Re: [PHP-DEV] Re:[PHP-DEV] [VOTE] array_key_first(), array_key_last(), array_value_first(),array_value_last()

[Côme Chilliet]

Le mercredi 11 juillet 2018, 07:37:56 CEST Levi Morrison a écrit :
> This is true. For completeness the fix is very mild:
> 
> if (([$_, $value] = array_first(some_function()) && $value > 3) {
> // do something
> }
> 
> I still think this is better. Forcing you to handle the error case is
> not a bad thing.

The point of these functions is to avoid complicated hard to read code for 
simple operations.
This if is hard to read for me and not much better that 
array_values(some_function())[0].

Côme

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

Re: [PHP-DEV] Re:[PHP-DEV] [VOTE] array_key_first(), array_key_last(), array_value_first(),array_value_last()

[Côme Chilliet]

Le mardi 10 juillet 2018, 18:41:17 CEST Levi Morrison a écrit :
> People who argue against the tuple because they don't like the design
> need to consider the bigger picture. 

My guess is people arguing for the tuple do not understand the usecase :-)

Each time I felt the need for array_first_value was because I was using it on a 
function return to do something with it.

Like:
if (array_first_value(some_function()) > 3) {
  // do something
}

Either I know that the array is not empty, or I do not care because NULL will 
be ignored correctly.
In the second case, with a tuple I’m stuck because if I do:

if (array_first(some_function())[1] > 3) {
  // do something
}

If array_first returns NULL this will trigger a PHP error. So I have to add 
more code to handle this special case while I do not need any with 
array_first_value.

Côme

Re: [PHP-DEV] [RFC] [VOTE] User-defined object comparison

[Côme Chilliet]

> $x->__equals($y) && $y->__equals($z) requires that $x->__compareTo($z) be 
> *TRUE*.

Typo here, it should be __equals at the end not __compareTo.

> In fact, returning 0 in __compareTo for undefined natural ordering leads to 
> all kinds of strange behaviour

If this is the case, I do not understand why you split comparison and equality, 
as I understood it at first the point was exactly to be able to have ordering 
equality without having value equality. If this leads to strangeness, why allow 
it?

Côme


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

Re: [PHP-DEV] Re: Add functions array_key_first() and array_key_last()

[Côme Chilliet]

Hello,

Shouldn’t we also add array_first and array_last for consistency?
reset and end may be used for this but they modify the array state and cannot 
be called on function results.

Côme

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

[PHP-DEV] PHP documentation for new functions

[Côme Chilliet]

Hello,

I added documentation for the new PHP-LDAP functions, for instance:
https://secure.php.net/manual/en/function.ldap-exop.php

It says «(No version information available, might only be in Git)», I did not 
find any way to change that.
I guess it’s somehow auto-detected? Why does it not see this function is in 7.2 
then?

Côme

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

[PHP-DEV] Merging LDAP controls support

[Côme Chilliet]

Hello,

I’m getting close to have something I can merge in master for my PR adding 
support for LDAP controls: https://github.com/php/php-src/pull/2640

In this case am I suppose to squash the changes in a single commit? This was 
suggested to me for a previous PR but there is so much changes here I feel we 
should keep the history.

If some of you can pull my branch and launch the tests from ext/ldap it would 
help. You’ll need an LDAP server and to fill the env vars from 
ext/ldap/tests/connect.inc.

Côme

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