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.
>
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
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.
>
>
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
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
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
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
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
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
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
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
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
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
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)
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
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
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
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,
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
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":
>
>
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
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
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):
>
>
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 $$
> > >
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);
&
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
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
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
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()
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
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:
> >
> >
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(
[
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.
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
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
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
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
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
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 pag
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:
>
>
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.
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
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
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
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
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
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
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
>
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
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);
>
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
.
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
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
y:
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.or
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 Ch
lders, 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
, 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 userlan
s
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
ken;
}
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
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
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
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
he 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, vi
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
his.
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(&
ameter 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 Dev
here 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 L
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
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 abl
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
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
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
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
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
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
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
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
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):
>
>
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 =
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
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
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
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
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,
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
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,
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
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
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
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
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
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
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
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
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
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
> $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
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
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
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
1 - 100 of 127 matches
Mail list logo
