Re: [PHP-DEV] [VOTE] Same Site Cookie RFC

Hi Sara, hi Frederik, Thinking more about this I came to change my vote (and for that reason I’ll take back the suggestion to include it into 7.2): The array API is the better API and allows for healthier future growth so we should pursue that option There is a (very ugly) workaround to s

Re: [PHP-DEV] [VOTE] Same Site Cookie RFC

Hi Sara, hi Frederik, Sounds good! Let's vote in getting it in first and then we can have a 2nd RFC (and vote) if it should land in 7.2 cu, Lars Sent from my electronic toy > On 26. Aug 2017, at 17:34, Frederik Bosch wrote: > > Hi Sara, > > Thanks for clearing this. I have no intension to h

Re: [PHP-DEV] [RFC] samesite cookie implementation

Hi everybody, I strongly believe this is something we should ship with 7.2. That would give the ecosystem a 1-year head with a feature that could eventually help eradicate CSRF. I would argue that this is worth the unorthodox circumnavigation of our policies. Do you think that’s outrageously

Re: [PHP-DEV] Missing reflection info about strict types?

> On 07 Sep 2016, at 10:13, Leigh wrote: > > On Mon, 5 Sep 2016 at 10:39 Nicolas Grekas wrote: [...] > As an aside, would you guys like to see a strict types indicator in debug > backtraces? I wrote a small patch for it back during development of 7, and > then forgot about it. > > https://gith

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

Hi Davey, thanks for the proposal and excuse my rather longish reply already. > On 02 Sep 2016, at 21:32, Davey Shafik wrote: [...] > I'd like to introduce a new RFC to deprecate pear/pecl (in 7.2, and remove > in 8.0), as well as add composer/pickle (optional in 7.2, default in 7.3+) > in their

Re: [PHP-DEV] [RFC][VOTE] Add validation functions to filter module

Hi Yasuo, > On 31 Aug 2016, at 21:45, Yasuo Ohgaki wrote: [...] > Thank you for voting! > The RFC is declined 1 vs 13 > A bit surprised this result. > > I requested the reason of objection, but many of them does not disclose why. [...] > lstrojny (lstrojny) [...] sorry for not chiming in earli

Re: [PHP-DEV] [RFC][Discussion] Parser extension API

Hi Alexander, > On 17 Feb 2015, at 12:46, Alexander Lisachenko > wrote: > > Hello, internals! > > I want to introduce a RFC for providing a userland API for accessing an > Abstract Syntax Tree of the source code and to provide userland parser > hooks for source code modification: > https://wi

Re: [PHP-DEV] [VOTE] Scalar Type Hints

Hi Matteo, sorry for the late response. > On 07 Feb 2015, at 12:46, Matteo Beccati wrote: > > Maybe it's just me, but I didn't quite understand the point you are making > here. Are you saying that declares are more or less like ini settings? Yes, exactly that. The new declare()-statement will

Re: [PHP-DEV] [VOTE] Scalar Type Hints

Hi Andrea, > On 05 Feb 2015, at 21:14, Andrea Faulds wrote: > [...] > Voting starts today (2015-02-05) and ends in two weeks’ time (2015-02-19). In > addition to the vote on the main RFC, there is also a vote on the type > aliases issue, and a vote to reserve the type names for future RFCs’ sak

Re: [PHP-DEV] [RFC] Static classes (Was Abstract final classes)

Hi Guilherme, hi Robert. > On 01 Dec 2014, at 14:58, Robert Stoll wrote: > > I am not sure what makes more sense for PHP, but just as thought-provoking > impulse, wouldn't it be better just to check that all methods are static and > __construct private instead of turning methods magically into

Re: [PHP-DEV] [RFC][Vote Cancellation] Return Types

Hi Levi, thanks for doing "the right thing"[tm] and cancelling the vote to open up the discussion. > On 07 Nov 2014, at 17:20, Levi Morrison wrote: [...] > If these were split into separate files and autoloaded > the current solution would work. > > class A { > function foo(): B {} > } > cl

Re: [PHP-DEV] [RFC] Safe Casting Functions

Hi Derick, > On 21 Oct 2014, at 17:26, Derick Rethans wrote: > > But what about if we also would like a to_bool, which would accept > "true", "false", "0", "1", true, false, 1 and 0? Yep, I think that totally makes sense. "yes" and "no" would be further candidates but that’s probably already

Re: [PHP-DEV] [RFC] Safe Casting Functions

Hi Andrea, > On 21 Oct 2014, at 00:57, Andrea Faulds wrote: > > Good evening, > > I am presenting a new RFC to add a set of three functions to do validated > casts for scalar types: > > https://wiki.php.net/rfc/safe_cast > > Please read it. I like the proposal except for one thing: the fun

Re: [PHP-DEV] [RFC] Exceptions in the engine

Hi Nikita, On 06 Oct 2014, at 23:53, Nikita Popov wrote: [...] > As such I'm re-proposing this RFC for inclusion in PHP 7: > >https://wiki.php.net/rfc/engine_exceptions_for_php7 > > The RFC text is essentially the same as previously, with the primary > difference being that parse errors are

Re: [PHP-DEV] Little switch improvement: get the used variable

Hi Rowan, On 26 Sep 2014, at 18:11, Rowan Collins wrote: [...] > Without the additional guarantees provided by a purely functional > environment, that's really just inverting the function header and if > statement. > > Adding an extra case to that still means repeating the operator, so isn't t

Re: [PHP-DEV] Little switch improvement: get the used variable

Hi everyone, On 24 Sep 2014, at 23:17, Rowan Collins wrote: > switch ( $number ) use ( === ) { [...] > switch ( $age ) use ( < ) { [...] > switch ( calculate_age($birth_date, $departure_date) as $age_at_departure ) > use ( < ) { [...] > switch ( $product ) use ( instanceOf ) { All of these exa

Re: [PHP-DEV] [VOTE] Fix list() behavior inconsistency

Hi everyone, On 25 Sep 2014, at 17:27, Patrick ALLAERT wrote: [...] > > I'm in favor of disabling for consistency as well, however, I wish a > warning would be emitted. Voted in favour of disabling as well but could easily live with the other option as everything is better then leaving the inc

Re: [PHP-DEV] Argument unpacking - Multiple unpacks and trailing arguments

Hi Nikita, Am 23.09.2013 um 21:33 schrieb Nikita Popov : [...] > An example of trailing arguments are array intersections and diffs using a > custom compare function: > >array_uintersect(...$arrays, $compare); >array_udiff(...$arrays, $compare); >// also array_intersect_uassoc and all

Re: [PHP-DEV] RFC: Anonymous Classes

Hi Joe, Am 23.09.2013 um 19:22 schrieb Joe Watkins : [...] > As I have said, serialization does work, and unserialization does work ... > > Classes do have unique names, so as long as the entry is present upon > unserialize you will get the object you expect ... if the entry is not > present

Re: [PHP-DEV] RFC: Anonymous Classes

Hi Joe, what about serialization for those classes? cu, Lars Am 23.09.2013 um 08:39 schrieb Joe Watkins : > Morning All, > >https://wiki.php.net/rfc/anonymous_classes > >I'd like to hear thoughts regarding the addition of anonymous classes, > patch included. > > Cheers > Joe > > --

Re: [PHP-DEV] Request #65501 uniqid(): More entropy parameter should be true by default

Hi Nikita, Am 24.08.2013 um 12:08 schrieb Nikita Popov : [] > We already have a great (version 4) UUID implementation called > mcrypt_create_iv, just minus the fixed sequences and fancy formatting. > Apart from moving this to core (not requiring mcrypt/openssl) and maybe > adding alphabet supp

Re: [PHP-DEV] Request #65501 uniqid(): More entropy parameter should be true by default

Hi everyone, adding UUID functionality to the core would be very cool. Especially in times where we create more and more primary keys in the code, not in the database. cu, Lars Am 23.08.2013 um 23:53 schrieb Yasuo Ohgaki : > Hi David, > > On Fri, Aug 23, 2013 at 12:03 PM, David Muir wrote: >

Re: [PHP-DEV] [RFC] Constant Scalar Expressions

Super cool, thanks! Am 13.08.2013 um 18:12 schrieb Anthony Ferrara : > Hello all, > > I'd like to propose a new RFC for 5.NEXT: > > https://wiki.php.net/rfc/const_scalar_expressions > > This allows for defining constant expressions which are resolved at compile > time. > > for example: > > c

Re: [PHP-DEV] RFC: constructor argument promotion

Hi Sean, thanks for your answers. Am 08.08.2013 um 02:54 schrieb Sean Cannella : > It does in the sense the same way as the current mode "enforces" types on > properties. That is, there's no guarantee that types will remain as > initially set, only that the values passed to the constructor must

Re: [PHP-DEV] RFC: constructor argument promotion

Hi Sean, thanks for the RFC. Two other questions additionally to what Stas askes: - What about class type hints and array type hints? - If type hints are possible, doesn’t it look too much as real property type hinting? cu, Lars Am 07.08.2013 um 21:47 schrieb Sean Cannella : > Everyone - >

Re: [PHP-DEV] RFC: Protocol Type Hinting

Hey Anthony, thanks for your work and I think it’s a very good idea. I thought very much of it during the last days and I start to see its merits. So, good thing. I would prefer ~Type for syntax over though, but that's just a minor detail. cu, Lars Am 25.06.2013 um 17:57 schrieb Anthony Ferra

Re: [PHP-DEV] Internal object orientation documentation available!

Thank you, thank you, thank you all! Am 10.06.2013 um 20:33 schrieb Nikita Popov : > Hi internals! > > We just published some rather extensive documentation on internal object > orientation: > >http://www.phpinternalsbook.com/classes_objects.html > > This is part of a larger project aimed

Re: [PHP-DEV] supporting the final keyword for properties

Hi Ferenc, Am 28.05.2013 um 08:15 schrieb Ferenc Kovacs : [...] >> I would like it to work the same way as it does in java( >> http://docs.oracle.com/javase/specs/jls/se7/html/jls-4.html#jls-4.12.4) >> eg. you can set the initial value either in the declaration or later on, >> but after it is set,

Re: [PHP-DEV] property de-referencing

Hi Rasmus, Am 25.04.2013 um 14:47 schrieb Rasmus Schultz : [...] > > What do you think? I'm not sure about the operator character but the general idea is a good one. Do you have a patch as a POC? cu, Lars -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://ww

Re: [PHP-DEV] Continued try blocks

Hi Julien, I'm still on the fence, not sure if it isn’t too opaque. Am 26.04.2013 um 16:41 schrieb Julien Pauli : [...] One question regarding scoping: does the next statement inherit the scope of the catch block like this? try { $user = $repository->findById(123); $user->setName($name);

Re: [PHP-DEV] DateTimeImmutable

Hi Derick, Am 27.03.2013 um 21:53 schrieb Derick Rethans : > On Tue, 26 Mar 2013, Michael Wallner wrote: > >> providing DateTimeImmutable as a sibling to DateTime. > > That's fine with me, but I am not having the time to work on a patch > right now. Happens. Let’s revert it till somebody find

Re: [PHP-DEV] RFC ? gethostbyname - getnameinfo()

I agree, PHP should have world-class support for v6. What is your proposal exactly? Am 27.03.2013 um 13:39 schrieb Sam Hermans : > Hi, > > The rcf howto pushed me into mailing you guys to measure reaction. > > For a project i am working on i struggle a lot with the fact that > $_SERVER['REMO

Re: [PHP-DEV] DateTimeImmutable

Not really, as an interface guarantees behavior, which is not possible for DateTimeImmutable and DateTime. Am 27.03.2013 um 09:03 schrieb Ferenc Kovacs : > 2013.03.26. 20:29, "Michael Wallner" ezt írta: >> >> Hi all! >> >> I am concerned by the introduction of DateTimeImmutable extending >> D

Re: [PHP-DEV] Questions regarding DateTimeImmutable

Start simple: ask Derick to revert and go through the usual RFC process. @Derick: given the overall response on the list, could you revert the introduction of DateTimeImmutable? cu, Lars Am 26.03.2013 um 01:21 schrieb Levi Morrison : > So how do we officially undo something that didn't use an

Re: [PHP-DEV] Questions regarding DateTimeImmutable

Am 25.03.2013 um 21:23 schrieb Sebastian Bergmann : > On 03/06/2013 10:50 AM, Nikita Popov wrote: >> I'd prefer to have nothing over having something bad. +1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

Yay! Am 07.03.2013 um 17:48 schrieb Zeev Suraski : > The voting period ended, and the option selected with 44 out of 70 votes > was integrating Optimizer+ into PHP 5.5.0, even at the cost of a minor > delay. An overwhelming majority (66 out of the 70 votes) was in favor of > going with the integ

Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

Hi Zeev, Am 28.02.2013 um 21:16 schrieb Zeev Suraski : > Ideally I'd like to get Xdebug compatibility for 5.5 - but even if we can't > make it - there's truth to the assertion you wouldn't want them both at the > same time. That’s not entirely true. If you stay as similar as possible to your pro

Re: [PHP-DEV] Allow (...)->foo() expressions not only for `new`

Hi Nikita, Am 25.02.2013 um 23:20 schrieb Bob Weinand : [...] >> When it comes to changing syntax, there is no such thing as too small >> of an RFC IMO. Runtime changes can occasionally be hand-waved, but >> syntax changes are serious business. I very much like it, it’s a good change. But can we

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

As a general reply: I’d like to disagree, and here is why. Yes, we should not let half baked features in but we need to add more and more features, also syntax wise. For three reasons: - Parity/expectations/me too: so you can do that in PHP as well - Expressiveness: allow better ways to expre

Re: [PHP-DEV] [RFC] Allow trailing comma in function call argument lists

Hi, Am 20.02.2013 um 06:24 schrieb Laruence : > On Tue, Feb 19, 2013 at 8:06 PM, Sara Golemon wrote: >> Opening RFC to allow trailing comma in function call argument lists >> >> https://wiki.php.net/rfc/trailing-comma-function-args -1 on this as well. If you don’t like the diffs, fix the diff

Re: [PHP-DEV] [RFC] Short syntax for anonymous functions

Hi Marcello, Am 19.02.2013 um 14:51 schrieb Marcello Duarte : > Thanks for the feedback. I get most people here don't appreciate the value of > the feature. > > I can understand that If you haven't tried to write a tool like capistrano, > rspec, chef, puppet, etc, etc in PHP you probably won't

Re: [PHP-DEV] PHP 5.5 upcoming roadmap

Hi David, thanks for the clarification, sounds like a plan :-) I'm not opposed to including O+, quite the opposite but I want us to stick to our process. cu, Lars Am 15.02.2013 um 19:14 schrieb David Soria Parra : [...] >> I'm sorry, but you must be kidding doing such a change and skipping >>

Re: [PHP-DEV] PHP 5.5 upcoming roadmap

Hi Julien, Am 15.02.2013 um 13:05 schrieb Julien Pauli : > Hello everyone, > > As you may know, Zend recently open sourced ZendOptimizer+ with a PHP > Licence. > We are planning to merge it to PHP5.5 Core (discussions on Mailing lists > and IRC) and have it bundled with PHP5.5 final release stab

Re: [PHP-DEV] Github pull request management

Hi Johannes, quick question: does it automatically open bug reports for each PR? Am 13.02.2013 um 17:03 schrieb Johannes Schlüter : > Hi, > > with Felipe's help I've just added the second pull request management > tool to mange pull requests. > > The first one is https://qa.php.net/pulls/ this

Re: [PHP-DEV] Status of pull request

Hi Jason, thanks for the reminder. Am 13.02.2013 um 14:03 schrieb Jason Gerfen : > Is it considered spamming the list to check the status of a pull request? I > am going to ask any ways, hope it doesn't offend. > > The pull request addresses bug fix/feature request #38917 implementing > native

[PHP-DEV] New SSL stream context option to prevent CRIME attack vector

Hi, we have an open PR for a new SSL stream context option to prevent the CRIME attack vendor. Anybody with more familiar knowledge of SSL should have a look: https://github.com/php/php-src/pull/269 cu, Lars -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://w

Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution

Hi Zeev, Am 29.01.2013 um 15:21 schrieb Rasmus Lerdorf : > On 01/29/2013 06:13 AM, Nikita Popov wrote: > >> I'm not sure I fully understand this. The RFC claims that Optimizer+ is >> already *now* fully compatible with PHP 5.5. And that it was also >> compatible when PHP 5.4 was released. So the

Re: [PHP-DEV] Patch: Specify temp directory

Hi Alex, could you open a pull request on GitHub for it. Makes managing things much easier. Other than an outstanding review, I see no reason not to include this functionality. cu, Lars Am 18.01.2013 um 15:01 schrieb ALeX Kazik : > Hi, > > some time ago I created a small patch to make it pos

Re: [PHP-DEV] [VOTE] array_column() function

It’s quite simple: - Do you want to include the functionality: yes/no - If you want to include it, which name should it have: array_column/array_pluck Am 14.01.2013 um 23:23 schrieb Gustavo Lopes : > On Mon, 14 Jan 2013 23:16:52 +0100, Pierre Joye wrote: > >> On Mon, Jan 14, 2013 at 11:01

Re: [PHP-DEV] [VOTE] array_column() function

Hi Ben, Am 14.01.2013 um 23:16 schrieb Pierre Joye : [...] > Up to you, but I'd to suggest again to re do the vote and add the > naming option, easy, clear, open. I was one of the people changing from yes to no because of the name. I like the functionality but I prefer no new array function over

Re: [PHP-DEV] [VOTE] array_column() function

Nope, it wasn’t rejected, there was simply no response for a really long time: https://github.com/php/php-src/pull/202 Am 14.01.2013 um 22:06 schrieb Herman Radtke : > On Sat, Jan 12, 2013 at 12:04 AM, Levi Morrison > wrote: >> The real problem here (in my opinion) is that `array_filter` does

Re: [PHP-DEV] Bug #23815: Added extra ImageCopyMergeAlpha function

Any news? Am 04.01.2013 um 13:45 schrieb Pierre Joye : > No need to create another function for that. I will do it once I am back at > work next week. > On Jan 3, 2013 12:33 PM, "Lars Strojny" wrote: > >> No objection from my POV. Going to merge it in around

Re: [PHP-DEV] [VOTE] array_column() function

Hi Ben, Am 12.01.2013 um 01:17 schrieb Ben Ramsey : > I've opened voting for the array_column() function RFC. > > You can vote at https://wiki.php.net/rfc/array_column#voting I voted yes, but I prefer to call it just array_pluck (no aliases). It’s what underscore.js calls it and my own pet pro

Re: [PHP-DEV] A remark about PHP's Vision and new things.

Hi Stas, I think you hit a nail here. Am 10.01.2013 um 21:36 schrieb Stas Malyshev : > Another thing is that we're not having some features that are used > extensively in C# annotations, main being named parameters support. To make sure we are not providing a somewhat cumbersome implementation

Re: [PHP-DEV] [RFC] Reflection annotations reader

Hi Yahav, Am 06.01.2013 um 22:58 schrieb Yahav Gindi Bar : [...] > In one of the discussions (about the "deprecated" keyword, to be specific), > it was been said that adding ability to read doc-comment annotation could > be handy. Personally, I really think it can be great. > > So, I've created a

Re: [PHP-DEV] [RFC] Fixing insecure cURL file uploading

Hi Stas, Am 06.01.2013 um 06:38 schrieb Stas Malyshev : [...] > Following the recent discussion on the list, I've drafted an RFC > describing the CurlFile solution for it here: > > https://wiki.php.net/rfc/curl-file-upload > > Please review and comment. If there's a general positive feedback, I'

Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 : parent::$foo Issue

Hi Clint, got it. Am 04.01.2013 um 16:28 schrieb Clint Priest : > Uhm.. brain fart. > > I was thinking $this->$foo was normal when I wrote this up, I would change my > last statement from the earlier email to any syntax which did not include a $. > > That being said then, I think I favor par

Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 : parent::$foo Issue

Hi Clint, Am 04.01.2013 um 04:13 schrieb Clint Priest : [...] > 1) It forces the user to access the parent property accessor in a different > way than is used everywhere else Isn’t that the same as parent->$foo? Please let’s not introduce a special syntax for something that can be done proper

Re: [PHP-DEV] Bug #23815: Added extra ImageCopyMergeAlpha function

No objection from my POV. Going to merge it in around a week, if no one objects. Am 02.01.2013 um 10:35 schrieb matt clegg : > I have added ImageCopyMergeAlpha as an extra function to resolve bug 23815. > > I have created a pull request on github > https://github.com/php/php-src/pull/211 > > Ca

Re: [PHP-DEV] [RFC] zend_parse_parameters() improvements

The is_null feature is really helpful. Thanks! Am 02.01.2013 um 16:26 schrieb Johannes Schlüter : > > > Gustavo Lopes wrote: >> I've written an RFC. It's available on: >> >> > > The patch is mssing an update to README.PARAMETER_PARSING and if you ant to

Re: [PHP-DEV] DateTime improvement

Hi Derick, I would go with DateTimeValue or DateTimeImmutable as well. Am 17.12.2012 um 19:42 schrieb Benjamin Eberlei : > On Mon, Dec 17, 2012 at 5:48 PM, Derick Rethans wrote: > I went for DateTimePoint. Point as in "Point in time". I am not too > happy with the name, but I think it works bet

Re: [PHP-DEV] DateTime improvement

This is so cool, thanks Derick! If you need help with testing or anything else, let me know. Am 16.12.2012 um 13:21 schrieb Derick Rethans : > On Tue, 11 Dec 2012, Derick Rethans wrote: > >> On Mon, 10 Dec 2012, Herman Radtke wrote: >> >>> Another option is to make an ImmutableDateTime class.

Re: [PHP-DEV] Core liason for PHP FIG

Hi Pierre, Am 16.12.2012 um 13:08 schrieb Pierre Joye : > This is something we have seen in the past, "legacy" core developers > were not really in sync with the community needs or wishes. That's why > we need them to work with the core instead of the other way 'round. It > will create more bridg

Re: [PHP-DEV] Core liason for PHP FIG

Hi Kris, thanks for your response. Just a short note: I'm not in any ways officially related to PHP FIG, except that I find it personally to be a good initiative. Rest of the answers below. Am 16.12.2012 um 11:50 schrieb Kris Craig : > My one concern with this idea is that it could give the er

[PHP-DEV] Core liason for PHP FIG

Hello everybody, for all of you who don’t know, PHP FIG (Framework Interoperability Group, http://www.php-fig.org/) discusses ways frameworks and libraries can work together and integrate much easier. Current PSRs are PSR-0 to standardize autoloading, PSR-1 and PSR-2 that deal with coding style

Re: [PHP-DEV] [RFC] Modify tempnam() to handle directories and auto-cleanup

Good idea! Am 26.11.2012 um 22:21 schrieb Sara Golemon : > https://wiki.php.net/rfc/request-tempnam > > Just a bit of hand-holding for those who don't remember to clean up > their messes. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/

Re: [PHP-DEV] Generics proposal

Cool! Looking forward to it. Am 07.11.2012 um 06:41 schrieb Sara Golemon : > Retrying this with reply-to-all. :) > > I think it's an awesome moment for PHP and HipHop to work together! :) > I'll summarize what we have so far into an RFC. > > -Sara > > On

Re: [PHP-DEV] Generics proposal

Hey Sara, can you already show us how your take on Generics would look like? Maybe this is a good moment for HipHop and PHP to do something together. Am 06.11.2012 um 04:14 schrieb Sara Golemon : > Sorry to be late to the conversation, but fwiw, HipHop is adding > Generics (and some other cool

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

Hi Stas, hi Etienne, let’s get practical and apply LSP to property accessors. Find below what I would read from the characteristics of LSP. Am 31.10.2012 um 20:46 schrieb Stas Malyshev : [...] >> Instead, LSP simply states that, given B <: A, all objects of A can be >> substituted by objects of

Re: [PHP-DEV] PR 186: external protocols and locale independent string conversion

Hi, thanks for bringing this up again. I digged even deeper into the whole issue of converting floats to strings and my current findings are that we can’t solve that consistently as things are already fubar’ed. The reason for that is, that in order to solve this issue we would need to make ever

Re: [PHP-DEV] Changing the default value of "true" for CURLOPT_SSL_VERIFYHOST

Hi, Am 25.10.2012 um 07:03 schrieb JJ : [...] > My solution was to check the type for CURLOPT_SSL_VERIFYHOST: if it is > boolean and true, the opt value for libcurl is set to 2L. > > I understand that engineers should have the proper option value to > begin with but weighing the impact of this (M

Re: [PHP-DEV] Generics proposal

Hi Rasmus, Am 20.10.2012 um 23:02 schrieb Rasmus Lerdorf : [...] > Personally I would hate to see this anywhere near PHP. Do you mind explaining the why? Isn’t it better than new Collection("TypeAsAString") and custom assertions in each and every method of that collection class? cu, Lars -- PH

Re: [PHP-DEV] PR 186: external protocols and locale independent string conversion

Hi, Am 19.09.2012 um 20:35 schrieb Lars Strojny : [...] > This kind of fix is very likely needed in other places, where floats are > converted using convert_to_string(). I haven’t found time to try e.g. > mysqlnd, but I suspect we’ll find similar issues there. I don’t think the &

[PHP-DEV] PR 186: external protocols and locale independent string conversion

Hi everybody, I'm currently working on https://github.com/php/php-src/pull/186, which fixes a problem with PostgreSQL when passing a float to pg_query_params() with a locale setting that uses "," as a decimal point. pg_query_params() uses convert_to_string(), which uses %G as a format string fo

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

Hi, Am 19.09.2012 um 18:11 schrieb Michael Stowe : > Personally, I would like to see it operate similar to MySQLi, where you > have the convenience of OOP, but can still call a function directly in a > procedural manner. There seems to be a need for a procedural API. As their is one, let’s do it

Re: [PHP-DEV] [VOTE] ::class feature to resolve namespaced class names to scalars

Hi, Am 13.09.2012 um 16:02 schrieb Marco Pivetta : > I don't think autoloading is needed here, since the FQCN can be resolved > without it (exactly like with type hinting). Has nothing to do with autoloading. It only checks if there is a use statement. Auto-loading is triggered during call time

Re: [PHP-DEV] [VOTE] ::class feature to resolve namespaced class names to scalars

Hi Dmitry, Am 13.09.2012 um 11:12 schrieb Dmitry Stogov : > We already have isset(), empty(), unset() that are a special purpose > functions handled by compiler. [...] That’s exactly my point: these special purpose functions present themself to the user as usual functions and set a certain exp

Re: [PHP-DEV] [VOTE] ::class feature to resolve namespaced class names to scalars

Hi Simon, Am 13.09.2012 um 10:34 schrieb Simon J Welsh : [...] > I would expect $variable::class to work (like late static bindings). [...] Than better try the patch, as it doesn’t work now :) But it is a good point indeed. @Ralph: what do you think? cu, Lars -- PHP Internals - PHP Runtime Dev

Re: [PHP-DEV] [VOTE] ::class feature to resolve namespaced class names to scalars

Hi Dmitry, Am 13.09.2012 um 10:17 schrieb Dmitry Stogov : [...] > I think the syntax is wired. > Instead of classname::class I would prefer something like class(classname). Wouldn’t this look too much like a function with all the implications that might cause like users expecting class($variable

Re: [PHP-DEV] get_class_vars() returned information ORDER

Hi, Am 09.09.2012 um 13:52 schrieb Johannes Schlüter : [...] > There's no such guarantee. The fact that it is using a Hashtable which has an > order is an implementation detail. This might change (even though a change is > unlikely) The only promise of get_class_vars() is to return all. Or put

Re: [PHP-DEV] New Feature: Fully qualified class name resolution as scalar with class keyword

Hi Ralph, Am 08.09.2012 um 20:03 schrieb Ralph Schindler : [...] >> What I find absolutely confusing is the use of Class vs. CLASS vs. class for >> constant names. Let’s limit the translation to FQCN. > > I will clean up the proposal make the examples more consistent (all lower > case). It's w

Re: [PHP-DEV] Easing major version upgrades

Hi Pierre, Am 08.09.2012 um 20:23 schrieb Pierre Joye : [...] > >> 3.) Upgrades are hard, let’s go shopping aka never change a running system > > What do you mean here? A general reluctance to change production systems because "they work". But as I said, not our problem. [...] > No chance to

Re: [PHP-DEV] New Feature: Fully qualified class name resolution as scalar with class keyword

Hi Ralph, I still like the proposal. Am 08.09.2012 um 07:12 schrieb Ralph Schindler : [...] >>> But yes, I agree that runtime resolution only duplicates existing >>> behavior, so it isn't really necessary (you could argue thought that >>> self::class similarly also only replicates the existing __

[PHP-DEV] Easing major version upgrades

Hi everybody, with the release of PHP 5.4 a similar pattern happened as with the release of 5.3: while we want people to upgrade as fast as possible, it is often a bumpy road for users to migrate to new versions. There are various reasons for it: 1.) Incompatible and hard to change codebases t

Re: [PHP-DEV] RFC for Adding __toString to DateTime

Hi Will, Am 03.09.2012 um 15:04 schrieb Will Fitch : [...] > > > Hi, Lester - I'll update the patch and RFC to include this format. This is > the format I'll use unless others have a better approach: > > 2012-09-01T00:00:00-0500 (America/Chicago) Psst ... microseconds ... pssst. Please includ

Re: [PHP-DEV] RFC for Adding __toString to DateTime

Hi Will, Am 03.09.2012 um 14:01 schrieb Will Fitch : > On Mon, Sep 3, 2012 at 7:57 AM, Pierre Joye wrote: [...] > I actually feel a static function which tracks globally would best serve > this case: > > date_default_format_set('c') > > This would prevent the need for setting it on a per insta

Re: [PHP-DEV] RFC for Adding __toString to DateTime

Hi Pierre, hi Will, Am 03.09.2012 um 13:57 schrieb Pierre Joye : > hi Will, > > On Mon, Sep 3, 2012 at 1:51 PM, Will Fitch wrote: >> On Mon, Sep 3, 2012 at 4:59 AM, Ryan McCue wrote: >> >>> As far as I can tell, there's no standard which uses the Olson database >>> to specify the timezone, so

Re: [PHP-DEV] A new php Validator and Filter interface for the SPL

Hi Axel, I think PHP core is just not the place for such standardization, as long as those interface do not interact with the engine (as i.e. Traversable does). Different frameworks might or might not agree on various interoperability standards and that’s fine. Having those interfaces in core w

Re: [PHP-DEV] [VOTE]Call for voting: support use list in foreach

Am 27.08.2012 um 03:55 schrieb Rasmus Lerdorf : [...] > And we aren't just C89 anymore actually. We still try to stick to it > when possible, but for example in the intl extension you will find C++ > and it won't build without it. The idea there is that any small embedded > platform that may still

Re: [PHP-DEV] [VOTE]Call for voting: support use list in foreach

Hi Gwynne, Am 27.08.2012 um 03:39 schrieb Gwynne Raskind : > (And > a side note on that, the requirement of C89 standard compliance in PHP > has less and less advantage these days, and handicaps those few > language features in the later flavors of C (C99, gnu99, Clang C, > etc.) which -could- le

Re: [PHP-DEV] Merging fix for quoted_printable_encode()

Hi everybody, patch + test merged to master and 5.4. I would really like to merge it to 5.3 as well but if others disagree I could live without it. With regards, Lars Am 20.08.2012 um 22:03 schrieb Lars Strojny : > Hi Stas, > > I would prefer it int 5.3 as well as it might brea

Re: [PHP-DEV] Merging fix for quoted_printable_encode()

Hi Stas, I would prefer it int 5.3 as well as it might break mailing systems using quoted_printable_encode(). I’ll add the test from the comments as well. Am 20.08.2012 um 20:30 schrieb Stas Malyshev : > Yes. For 5.3, it does not look like a critical bug, so it shouldn't be > there. Also, the t

[PHP-DEV] Merging fix for quoted_printable_encode()

Hi everybody, I would like to merge https://github.com/php/php-src/pull/120 in HEAD, 5_4 and 5_3 to fix splitting of soft line breaks. Any concerns? With regards, Lars -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Support negative indexes for arrays and strings

Hi Marc, Am 17.06.2012 um 21:53 schrieb Marc Easen: [...] > Numerical keyed array: > >$a = array('foo', 'bar', 'baz'); >$a[0] === 'foo' > > I would expect: > >$a[-1] === 'baz'; > > An string keyed array: > >$b = array('foo' => 1, 'bar' => 2, 'baz' => 3); >$b[0] === 1; >

Re: [PHP-DEV] [VOTE] Vote change for empty() RFC

Hi Rafael, hope it’s ok I've reopened the vote temporarily, but you’ve got the missing vote. Am 21.05.2012 um 01:05 schrieb Rafael Dohms: > On Mon, May 21, 2012 at 12:44 AM, Pierre Joye wrote: >> >> >> See the previous mails, as long as other voters agree to change their >> votes to empty on

Re: [PHP-DEV] Internals books (c) 2007+ ?

Yep, that might be exactly the problem. The audience for such a book might be less than 100. Am 17.05.2012 um 06:24 schrieb Sanford Whiteman: >> Sara’s book is still the best we have, nevertheless it shows its >> age. In Theo Schlossnagles "Scalable Internet Architectures" also >> has a chapter

Re: [PHP-DEV] Internals books (c) 2007+ ?

Hi Sanford, Sara’s book is still the best we have, nevertheless it shows its age. In Theo Schlossnagles "Scalable Internet Architectures" also has a chapter on PHP internals. The rest is more or less reading existing code and playing around. Looks like somebody on Internals should land a book d

Re: [PHP-DEV] New Feature: Fully qualified class name resolution as scalar with class keyword

Hi Ralph, hi everybody, given the clear use case and the simplicity of the patch, a very good idea. With regards, Lars Am 15.04.2012 um 16:13 schrieb Ralph Schindler: > >> I used to implement `public static function getClass() { return >> get_called_class(); }`, so I really like this one, mak

Re: [PHP-DEV] Multiple Visibility Level Getters/Setters

Just throw an error if conflicting accessors are defined. In the case of subtypes: accessors may broaden the interface, but not limit it => LSP. So it’s fine to make a parents protected accessor public, but not the other way around. Am 19.11.2011 um 02:46 schrieb Clint M Priest: > What would ev

Re: [PHP-DEV] weak references

While I like SplWeekRef and the somewhat proposed SplWeekRefList, you’ll find attached a patch that exposes a simple function „refcount“ having this signature: int refcount(mixed value) So if you would like to play around with it, have fun. It would be interesting to see if there are any other us

  1   2   3   >