Re: [PHP-DEV] Question/comment about the Array to String conversion RFC

On Thu, Mar 19, 2015 at 1:40 PM, Dan Ackroyd dan...@basereality.com wrote: On 19 March 2015 at 17:14, François Laupretre franc...@php.net wrote: As you may have noticed if you had a look at the RFC or twitter, I have decided to follow people's suggestion. Please note that the switch from

[PHP-DEV] [VOTE] Reserve even more type hints

The voting period for the Even More type hints reservation RFC is now open. Reminder, any types reserved via this RFC are dependent on at least one of the STH RFCs passing, or Levi's base types reservation RFCs passing as it's silly without at least one of those.

Re: [PHP-DEV] Re: [RFC] Reserving More Types in PHP 7

On Fri, Feb 20, 2015 at 8:00 AM, Levi Morrison le...@php.net wrote: On Fri, Feb 20, 2015 at 6:01 AM, François Laupretre franc...@php.net wrote: Add 'resource', 'object', 'scalar', 'mixed', 'numeric' If someone wants to reserve these I will leave them up to another RFC, as I suspect they are

[PHP-DEV] [RFC] Reserve EVEN MORE types for PHP7

Announcing this in its own thread: https://wiki.php.net/rfc/reserve_even_more_types_in_php_7 This RFC acts as an addition to Levi's https://wiki.php.net/rfc/reserve_more_types_in_php_7 by creating a forum for voting on additional types not included in his RFC: resource, object, scalar, mixed,

Re: [PHP-DEV] Remove old PHP6 forward compatibility

On Wed, Apr 29, 2015 at 4:12 PM, Stanislav Malyshev smalys...@gmail.com wrote: Back when PHP6 was actually a thing, we added the 'b' string literal prefix and the (binary) cast to be forward compatible with PHP6, however since the entire unicode strings part were dropped, these are no longer

Re: [PHP-DEV] Add support $object::class

On Mon, Apr 27, 2015 at 10:28 AM, S.A.N ua.san.a...@gmail.com wrote: Why not? 1. get_class($object) - looks bad and long It's a function call. A pretty much self-declarative one at that. What is bad about it? For that matter, what's long about it? It's pretty short as PHP function calls go.

Re: [PHP-DEV] Undefined variables undefined order

On Mon, May 11, 2015 at 5:12 PM, Matt Wilmas php_li...@realplain.com wrote: - Original Message - From: Stanislav Malyshev smalys...@gmail.com Sent: Monday, May 11, 2015 argument. I'd like to propose making the order of evaluation defined by splitting this into separate statements:

[PHP-DEV] Undefined variables undefined order

http://3v4l.org/uVNIS Prior to PHP 5.1 (and the introduction of compiled variables), the following code would output warnings for the undefined variables in the order they were used: echo $x . $y . $z; However, with the introduction of CVs, we wind up getting the warning for $y, then $x, and

Re: [PHP-DEV] Thoughts on C version supported for PHP-Next

On Fri, May 8, 2015 at 9:23 PM, Pierre Joye pierre@gmail.com wrote: Maybe we can create a repo on github to share them? I can create one, yes I prefer github than PHP's git, much easier to manage, issues, etc I say go for it, since you're our liason to the MSVC team. For me, I agree with

Re: [PHP-DEV] Undefined variables undefined order

On Mon, May 11, 2015 at 10:44 PM, Andi Gutmans a...@zend.com wrote: I don't think it is worth the change. I actually prefer to leave code path optimization up to gcc here vs. trying to tell it what to do. This isn't about optimizing code paths, it's about changing undefined behavior into

[PHP-DEV] [RFC] [CLOSED] Reserve even more types

https://wiki.php.net/rfc/reserve_even_more_types_in_php_7 is now closed (a bit late). Scalar will NOT be reserved in PHP7, however by votes of greater than 2/3rd, the following typenames are now reserved: Resource Object Mixed Numeric -- PHP Internals - PHP Runtime Development Mailing List To

Re: [PHP-DEV] [VOTE] Reserve even more type hints

On Mon, Apr 6, 2015 at 7:57 AM, Christoph Becker cmbecke...@gmx.de wrote: This vote was supposed to end on 29/3 but it seems to still be open. Can someone with proper access finish it? To my knowledge, everyone with a VCS account could do this. Sorry, I got really busy with other things and

Re: [PHP-DEV] Soft-reserve void class name

On Tue, May 19, 2015 at 9:16 AM, Levi Morrison le...@php.net wrote: I strongly disagree with this action. These types required an RFC; why should this be different? Also note that neither of the reserve typename RFC were unanimous. Furthermore, we are past the RFC stage. We are *supposed to

Re: [PHP-DEV] Method call overhead

On Jun 4, 2015, at 10:00, Rowan Collins rowan.coll...@gmail.com wrote: : http://3v4l.org/l75kf HHVM's percentages are lower primarily because its for loop measure is much slower in absolute terms. At the risk of distracting from the central topic, I'd like to point out that HHVM's times

Re: [PHP-DEV] Method call overhead

On Wed, Jun 3, 2015 at 3:33 PM, Brian Moon br...@moonspot.net wrote: On 6/2/15 22:30 , Bishop Bettini wrote: I've measured the overhead for method calls in a variety of environments (Amazon, Travis, and 3v4l). The results are reliable and here's 3v4l http://3v4l.org/NsjJR. Some

Re: [PHP-DEV] Method call overhead

On Jun 3, 2015, at 00:50, Michael Wallner m...@php.net wrote: On 03 06 2015, at 05:30, Bishop Bettini bis...@php.net wrote: My question though is on relative times. Method call overhead is consistently 50% to 150% over a direct call. Is my experiment invalid, or is this overhead

Re: [PHP-DEV] Migrating PHP classes to built in namespace

On Wed, Jun 3, 2015 at 1:33 AM, Dominic Grostate codekest...@googlemail.com wrote: Has there been any discussion or consideration towards migrating or at least aliasing all built in classes to a Php vendor namespace? Not any that's led to a consensus. Personally, I like the idea of moving

Re: [PHP-DEV] Undefined variables undefined order

On Tue, Jun 9, 2015 at 6:05 AM, Matt Wilmas php_li...@realplain.com wrote: Hah, looks like this just changed last week after barely 3 weeks. :-P I didn't verify, just noticed the code change: http://git.php.net/?p=php-src.git;a=commitdiff;h=c09698753e7d1d95299dca54c8ca888c885fd45b Dmitry,

Re: [PHP-DEV] Undefined variables undefined order

On Wed, Jun 10, 2015 at 7:50 AM, Sara Golemon poll...@php.net wrote: On Wed, Jun 10, 2015 at 7:42 AM, Sara Golemon poll...@php.net wrote: Dmitry, what's the reasoning behind this diff in the first place? Doesn't the compiler fold (const-string . const-string) already anyhow? How would we wind

Re: [PHP-DEV] Undefined variables undefined order

On Wed, Jun 10, 2015 at 7:42 AM, Sara Golemon poll...@php.net wrote: Dmitry, what's the reasoning behind this diff in the first place? Doesn't the compiler fold (const-string . const-string) already anyhow? How would we wind up with CONCAT_CONST_CONST at runtime? Derp. Looked again, and it's

Re: [PHP-DEV] [RFC] Simplified Array API for extensions

Not thoroughly tested, but it compiles at least. Give the latest commit a shot: https://github.com/sgolemon/php-array-api/commit/1274a2bcbc3eca78dbd35702136b0034b67afc8f -Sara On Fri, May 29, 2015 at 1:25 PM, Sara Golemon poll...@php.net wrote: Ah, well that I'll probably do soonish, but as you

Re: [PHP-DEV] [RFC] Simplified Array API for extensions

Yeah, way too late for PHP 7.0, but on the plus side the zend hash API has changed in ways which make this facade much less necessary. Not redundant, necessarily, but the biggest pain point (getting zval** by reference) is gone (we now get zval* via return). -Sara On Fri, May 29, 2015 at 12:14

Re: [PHP-DEV] [RFC] Simplified Array API for extensions

PHP5 for projects already using it :] -Hannes On Fri, May 29, 2015 at 12:33 PM, Sara Golemon poll...@php.net wrote: Yeah, way too late for PHP 7.0, but on the plus side the zend hash API has changed in ways which make this facade much less necessary. Not redundant, necessarily

Re: [PHP-DEV] [RFC] UString

On Tue, Jun 30, 2015 at 10:36 PM, Joe Watkins pthre...@pthreads.org wrote: Another possible issue is engine integration: $string = (UString) $someString; $string = (UString) someString; That sounds as a cool idea to discuss as a completely separate, unrelated RFC, and not specific to

Re: [PHP-DEV] [RFC] UString

On Thu, Jul 2, 2015 at 6:43 AM, Ivan Enderlin@Hoa ivan.ender...@hoa-project.net wrote: Just a small detail. Please, choose another name. The `Hoa\String` https://packagist.org/packages/hoa/string library has been renamed to `Hoa\Ustring` because of PHP7. So, please, don't force us to rename the

[PHP-DEV] C++ Extensions

PHP7's 64bit support in Zend/zend_long.h uses INT64_MIN/MAX as well as INT64_C/INT32_C concat macros. In C++, these are only defined if __STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS has been set prior to including stdint.h A C++ extension developer could deal with this by defining those prior to

Re: [PHP-DEV] C++ Extensions

On Wed, Aug 19, 2015 at 1:10 PM, Stanislav Malyshev smalys...@gmail.com wrote: A) Adding those defines prior to including stdint.h B) Expecting C++ ext devs to define those before including php.h C) Modifying zend_long.h to use things like std::numeric_limitsint64_t() when __cplusplus is

Re: [PHP-DEV] [RFC] UString

On Mon, Mar 2, 2015 at 12:48 AM, Nikita Popov nikita@gmail.com wrote: On Tue, Oct 21, 2014 at 9:06 AM, Joe Watkins pthre...@pthreads.org wrote: https://wiki.php.net/rfc/ustring This is the result of work done by a few of us, we won't be opening any vote in a fortnight. We

Re: [PHP-DEV] RFE to allow dirname($foo, 2)

On Wed, Jul 22, 2015 at 4:55 AM, Remi Collet r...@fedoraproject.org wrote: See https://bugs.php.net/bug.php?id=70112 I'm not inherently against it, but this really really sounds like a job for a userspace function. function dirname_n($path, $n) { while (($path !== '.') $n--) $path =

Re: [PHP-DEV] JsonSerializable New Interface method Proposal

On Mon, Jul 13, 2015 at 8:03 AM, Ryan Pallas derokor...@gmail.com wrote: Ive just opened a new RFC https://wiki.php.net/rfc/jsonserializable regarding Json to Object unserialization. I like the idea, but how do you handle complex json notations, that may contain arrays of objects? Say: {

Re: [PHP-DEV] Support for writing and executing compiled opcode

On Fri, Nov 13, 2015 at 1:35 PM, Stephen Coakley wrote: > I've been thinking about PHP optimization and distribution, and I would like > to hear some opinions on introducing a new feature for a future PHP 7 > version. Here's the concept: allow PHP opcode to be both saved

Re: [PHP-DEV] Support for writing and executing compiled opcode

On Mon, Nov 16, 2015 at 12:13 PM, Jefferson Gonzalez wrote: > On 11/14/2015 08:03 PM, Rasmus Lerdorf wrote: >> >> Beyond that I can't picture what possible use this could be. > > > I also think that the ability to have a .phpc and .php side by side would be > nice, but not for

Re: [PHP-DEV] [RFC][DISCUSSION] Revisit trailing commas in function arguments

On Thu, Oct 15, 2015 at 1:08 PM, Nikita Popov wrote: >> I would say that it should be modified to disallow a trailing comma >> following either a variadic declaration or a splat invocation, since >> the grammar around these two things prohibits followups anyway. > > > We

Re: [PHP-DEV] [RFC][DISCUSSION] Revisit trailing commas in function arguments

On Thu, Oct 15, 2015 at 12:51 PM, Ryan Pallas wrote: > I do h ave one question I just thought of though... how does the allowance > of trailing comma work with the splat operator (...)? I'm assuming a > function call/definition may only have one or the other, is that

Re: [PHP-DEV] [RFC][DISCUSSION] Revisit trailing commas in function arguments

On Wed, Oct 14, 2015 at 11:59 PM, Björn Larsson wrote: > Given the reason against this RFC in the thread it would be interesting > to know why HHVM decided to implement it? > Happy to answer, but I need to state a couple things first: * I don't really care if this

Re: [PHP-DEV] [RFC][DISCUSSION] Revisit trailing commas in function arguments

On Thu, Oct 15, 2015 at 12:32 PM, Pedro Cordeiro wrote: > I see no reason to allocate resources to make this happen, but if someone > does allocate their personal time into coding this, I wouldn't oppose a > merge. > There's a diff attached to the RFC. The actual

Re: [PHP-DEV] [RFC][DISCUSSION] Revisit trailing commas in function arguments

On Thu, Oct 15, 2015 at 12:16 PM, Ryan Pallas wrote: > But its an entirely stylistic choice to use trailing commas for cleaner > diffs. You could also use leading commas as well. If you made that a coding > standard for the organization, you would not have needed to

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

On Sep 6, 2015, at 07:01, Bob Weinand wrote: > Also, Hack is using a completely different parser, doesn't look like we could > borrow anything there. > True, Hack's parser is ocaml based and unrecognizable to the majority of this list. But HHVM's parser (which implements

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

On Sep 6, 2015, at 18:19, Bob Weinand wrote: > Oh, I thought that feature to be Hack-only. Looks like I'm wrong and hence > looked at the wrong place. [I always heard Hack has short Closures, but never > was told HHVM had them too...] Semantics semantics semantics. Short

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

On Mon, Aug 31, 2015 at 12:29 PM, Bob Weinand wrote: > The short Closures RFC: > https://wiki.php.net/rfc/short_closures > I just want to toss in my two cents as someone who's been using short closures on a PHPish platform for some time already, because predictions are one

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

On Wed, Sep 2, 2015 at 3:48 PM, Rowan Collins wrote: > Amendment 1. Only allow the single-expression form of the short syntax; full > function bodies must be declared with the existing function(){ ... } syntax. > This gives a clearer distinction between how the two

Re: [PHP-DEV] async/await - is future reserved words in PHP 7.x?

On Tue, Sep 29, 2015 at 3:00 PM, Dmitry Stogov wrote: > I think, we don't need to reserve words, until we decide to implement this. > The context sensitive scanner introduced in 7.0 makes the problem less > serious. > > $ sapi/cli/php -r 'class foo { static function use() {echo

Re: [PHP-DEV] [RFC] [VOTE] Short Closures

On Fri, Oct 2, 2015 at 12:33 PM, Björn Larsson wrote: > Leaves the options, >==, <== or >>=, <<=. But I don't like the > last ones. One might also consider extending the spaceship > operator to <==> for strict comparison. > Shift-left assign: >>= Shift-right assign: <<=

Re: [PHP-DEV] Strings, invalid escape sequences and parse errors

On Fri, Oct 2, 2015 at 6:53 AM, Bishop Bettini wrote: > On Fri, Oct 2, 2015 at 4:18 AM, Peter Cowburn > wrote: > >> a) change all other "invalid" escape sequences to be a parse error [that >> would mean "\m" would raise a parse error!] >> >> b) change \u{}

Re: [PHP-DEV] Re: [RFC] [VOTE] Short Closures

On Thu, Sep 24, 2015 at 12:10 AM, Stanislav Malyshev wrote: >> As a PHP developer, I agree with the possible confusion between `->` and >> `~>`. >> `==>` is a better choice IMHO, for its similarity with Hacklang syntax, as >> said previously. > > I'm getting a feeling the RFC

Re: [PHP-DEV] [RFC] [VOTE] Short Closures

On Mon, Sep 28, 2015 at 2:29 PM, Björn Larsson wrote: > ... or if someday in the future comparison operator > without type juggling is needed. > You just blew my mind. Trying to imagine where strict greater-than-or-equal would be used, and more to the point: What you'd

Re: [PHP-DEV] async/await - is future reserved words in PHP 7.x?

On Mon, Sep 28, 2015 at 10:30 PM, Pierre Joye wrote: > This model totally failed for us in the past. And given that these keywords > will be used for anything related to async APIs, let reserve them and put > our users on the safe side already. > Like that time we reserved

Re: [PHP-DEV] Re: [RFC] HTTP/2 Server Push support in ext/curl

On Tue, Dec 1, 2015 at 12:42 PM, Davey Shafik wrote: > I wanted to give another update, thanks to the input of Sean DuBois, the > patch is now pretty much final. There is one more memory leak, but I > believe it's in libcurl itself, I'll follow up over there on that. > > Sara

[PHP-DEV] [RFC] Differentiate op from assign-op in operator overloading

This is a separate proposal from the userspace operator overloading I put up for Patricio yesterday and aims to fix what I see as a bug in our operator overloading implementation (though some may disagree). It specifically only seeks to differentiate const operations which produce a new value

[PHP-DEV] [RFC] Normalize token_get_all() output (with flag)

I swear, 2016 isn't going to be "An RFC per day" year, but... https://wiki.php.net/rfc/token-get-always-tokens This should be pretty non-controversial. I hope? -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Normalize token_get_all() output (with flag)

On Mon, Jan 4, 2016 at 4:21 PM, Stanislav Malyshev wrote: > I think it's a great idea, token_get_all() is annoying > to deal with. We'd have to fix token_name though so that this would > still work: > Ah, excellent point! > We could, of course, do something like >

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

On Mon, Jan 4, 2016 at 8:40 PM, Paul M. Jones wrote: >> No definitions, no oversight, just straight up "the will of the star >> chamber." It's naked power masquerading as care-and-respect. > Please, offer definitions. Offer paths to oversight you deem sufficient. An RFC is

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

On Mon, Jan 4, 2016 at 4:37 PM, Stanislav Malyshev wrote: > It also provides a way for 5 (or, since CoC mechanisms are not specified > at all, even 3 assuming CoC decides by majority) people to accuse any > member of the community of some pretty dark things (without even

Re: [PHP-DEV] [RFC] Normalize token_get_all() output (with flag)

On Mon, Jan 4, 2016 at 7:38 PM, Stanislav Malyshev wrote: >> Do you mean have users of the API do that? Or have the implementation >> of token_name() do that? Because the latter doesn't seem unreasonable >> at all. > > I meant for token_name() to do that internally, so that

Re: [PHP-DEV] Deprecation of the Error Control Operator (@ symbol)

On Thu, Dec 31, 2015 at 1:10 PM, Stanislav Malyshev wrote: > I don't think it is a good idea, currently, for the following reasons: > [::snip::] It terrifies me to say this, but I completely agree with Stas. ;) I can't personally remember the last time I used @ in any

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

On Mon, Jan 4, 2016 at 8:34 PM, Paul M. Jones wrote: >> There is supervision, there is oversight. >> The oversight is this list. Any council issuing temp-bans without >> justification will be sanctioned. >> I'm quite certain that you, among others, will see to that. > > If

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

On Mon, Jan 4, 2016 at 8:26 PM, Paul M. Jones wrote: > This RFC is not about "respect." It is about a cabal being able to ban at > will, without supervision or oversight, based on their own whims. The > "respect" bit is a velvet glove on an iron fist. > There is

Re: [PHP-DEV] Deprecation of the Error Control Operator (@ symbol)

On Mon, Jan 4, 2016 at 9:45 PM, Sara Golemon <poll...@php.net> wrote: > On Thu, Dec 31, 2015 at 6:52 AM, Junade Ali <m...@junade.com> wrote: >> I am looking to submit an RFC in order to remove the error suppression >> operator in PHP, namely the @ symbol. >>

Re: [PHP-DEV] Deprecation of the Error Control Operator (@ symbol)

On Thu, Dec 31, 2015 at 6:52 AM, Junade Ali wrote: > I am looking to submit an RFC in order to remove the error suppression > operator in PHP, namely the @ symbol. > Forwarding a suggestion twitter/@Beryllium9: How about a global "disable error suppression" setting? That way a

Re: [PHP-DEV] RFC Operator Overloading in Userspace

On Sat, Jan 2, 2016 at 6:59 PM, Stanislav Malyshev wrote: >> Patricio Tarantino has asked me to help him propose Operator >> Overloading in PHP 7.1 (based in part on my operator extension in >> PECL). I think we can expose this to usespace as magic methods with >> very

[PHP-DEV] RFC Operator Overloading in Userspace

Patricio Tarantino has asked me to help him propose Operator Overloading in PHP 7.1 (based in part on my operator extension in PECL). I think we can expose this to usespace as magic methods with very little overhead (the runtime check and dispatch is already there, after all). I do think that

Re: [PHP-DEV] RFC Operator Overloading in Userspace

> BTW, I don't think for GMP right now += modifies existing object. > I guess it may be possible to implement it the other way (not sure). > It doesn't. As seen below, we get a new, second object on the assign_add. Wrong behavior IMO, but something to fix separately from this. $g =

Re: [PHP-DEV] Deprecation of the Error Control Operator (@ symbol)

On Tue, Jan 5, 2016 at 3:57 AM, Zeev Suraski wrote: >> From: Derick Rethans [mailto:der...@php.net] >> That's going to mean an INI setting.. that hosters could abuse. >> Having an INI setting like this as part of core is IMO not a great idea. > I honestly don't understand why

Re: [PHP-DEV] [RFC] Differentiate op from assign-op in operator overloading

On Mon, Jan 4, 2016 at 1:39 AM, Nikita Popov wrote: > I'd like to provide some context as to why the current implementation works > as it does. > Thanks for the context, Niki. It makes sense that, with GMP as the flagship target of operator overloading, stripping away the

Re: [PHP-DEV] Deprecation of the Error Control Operator (@ symbol)

On Tue, Jan 5, 2016 at 9:37 AM, Andrea Faulds wrote: >> How about a global "disable error suppression" setting? That way a >> project lead could enforce it for their codebase (and guarantee that >> devs "aren't lazy"), but PHP doesn't lose its pragmatism? > > I don't think that

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

On Tue, Jan 5, 2016 at 10:27 AM, Kevin Smith wrote: > Much of the argument in favor of a code of conduct seems to be centered > around the desire to send a message to the wider developer world that we’re a > welcoming community that doesn’t look kindly on poor treatment of

Re: [PHP-DEV] Deprecation of the Error Control Operator (@ symbol)

On Tue, Jan 5, 2016 at 10:09 AM, Ferenc Kovacs wrote: >> > I don't think that would work out too well. Remember that many projects >> > have >> > error handles which convert all errors to exceptions: if you disable @ >> > in >> > those projects, wouldn't their code break? >> >

[PHP-DEV] Re: [RFC] Normalize token_get_all() output (with flag)

On Mon, Jan 4, 2016 at 2:56 PM, Sara Golemon <poll...@php.net> wrote: > https://wiki.php.net/rfc/token-get-always-tokens > A suggestion from a co-worker who's worried about seeing patterns like: case ($t['token']) { case T_PAAMAYIM_NEKUDOTAYIM: // do something break

Re: [PHP-DEV] Re: [RFC] [Draft] Adopt Code of Conduct

On Thu, Jan 7, 2016 at 2:51 PM, Zeev Suraski wrote: > Having a CoC which is wider in scope and ratified by a voted RFC rather > than an email on some mailing list sends a strong message. Having it in > our contributor guidelines would also go a long way. > > I guess here we

Re: [PHP-DEV] [RFC] Normalize token_get_all() output (with flag)

On Tue, Jan 5, 2016 at 6:16 AM, Nikita Popov wrote: > Would be nice if someone could come up with a more explicit name for the > flag. TOKEN_FULL is not obvious, at least to me. TOKEN_ALWAYS_ARRAY? > Yeah, I'm not a huge fan of the name either, but I couldn't come up with

Re: [PHP-DEV] Re: [RFC] [Draft] Adopt Code of Conduct

On Tue, Jan 5, 2016 at 12:21 PM, Anthony Ferrara wrote: >>> It's been mentioned that we may want to adopt a CoC, but it shouldn't >>> "have teeth". I disagree here, as without an enforcement mechanism it >>> basically is no different from where we are at today. >> >> I think

Re: [PHP-DEV] Re: [RFC] Normalize token_get_all() output (with flag)

On Tue, Jan 5, 2016 at 12:52 PM, Andrea Faulds wrote: > This is more of a side-note, but maybe it's worth bringing up. Since > token_get_all gives an array with subarrays of a regular structure, might it > be worthwhile returning an array of objects instead? It would probably >

Re: [PHP-DEV] token_get_all(): additional location information, and raw tokens

On Tue, Jan 5, 2016 at 3:57 PM, Fred Emmott wrote: > - T_ELSEIF to T_ELSE T_WHITESPACE T_IF > HHVM only does that when the text of T_ELSEIF is "else\w+if" which happens because of a fugly lexer hack which yeah... let's not talk about that. -Sara -- PHP Internals -

Re: [PHP-DEV] Deprecation of the Error Control Operator (@ symbol)

On Tue, Jan 5, 2016 at 11:40 AM, Rowan Collins wrote: >> @ changes the error_reporting() level for that particular call, so those >> custom error handler won't throw exceptions for the suppressed errors but >> when you remove/nop @ their code would throwing stuff left and

Re: [PHP-DEV] Deprecation of the Error Control Operator (@ symbol)

On Tue, Jan 5, 2016 at 12:24 PM, Aaron Piotrowski wrote: > Before anything can be done with the @ operator, changes will need to > be made to remove warnings for conditions that the code has no way of > checking prior to calling these functions. > I'd include pragmatism in that

Re: [PHP-DEV] RFC Operator Overloading in Userspace

> On Jan 3, 2016, at 02:11, Nikita Popov wrote: > Thanks for the proposal, Sara! A few questions to clarify: > One point of order. It's Patricio's peoposal, I'm just helping him move it along. > 1. If an object implements __add__, will $a += $b be equivalent to $a = >

Re: [PHP-DEV] Re: [RFC] [Draft] Adopt Code of Conduct

On Wed, Jan 6, 2016 at 8:34 AM, François Laupretre wrote: > So, let's analyze what happened when I was accused of 'sabotage' and > 'strong-arming' because I had sent a supposedly offending mail to Sara. In > my reply, I published the mail in question so that everyone could

Re: [PHP-DEV] [RFC] Normalize token_get_all() output (with flag)

On Wed, Jan 6, 2016 at 1:43 AM, Nikita Popov <nikita@gmail.com> wrote: > On Tue, Jan 5, 2016 at 8:45 PM, Sara Golemon <poll...@php.net> wrote: >> Maybe TOKEN_ASSOC? Since it provides associative array elements (as >> opposed to the current indexed array behavior)

Re: [PHP-DEV] [RFC] Normalize token_get_all() output (with flag)

On Wed, Jan 6, 2016 at 1:43 AM, Nikita Popov wrote: > Basically: token_get_all() is rather slow. I think it says something that > getting the tokens of a script is about as slow as lexing it, parsing it > into an internal AST and constructing an object-based userland AST for

Re: [PHP-DEV] Re: [RFC] [Draft] Adopt Code of Conduct

On Wed, Jan 6, 2016 at 11:24 AM, Stanislav Malyshev wrote: >> I'm glad you brought this back up, but you seem to have remembered a >> few things incorrectly. > > And this is a good example why information from both sides is essential. > Everybody has their own story, and

Re: [PHP-DEV] Multicatch RFC proposal

On Thu, Dec 24, 2015 at 2:40 PM, Bronisław Białek wrote: > I've just created an RFC draft for catching multiple exception types > in one catch statement: > https://github.com/bronek89/php-multicatch-rfc > > I wrote RFC on github to check if there is any positive response from

Re: [PHP-DEV] Native Annotation Syntax

On Tue, Nov 24, 2015 at 11:05 AM, Rowan Collins wrote: > At first sight, these seem like details which could be tweaked later, but > they make a difference to what syntax to standardise: is the annotation name > just a string, or a valid class name? is the value of the

Re: [PHP-DEV] Re: [RFC] Normalize token_get_all() output (with flag)

On Tue, Jan 12, 2016 at 9:07 AM, Rouven Weßling wrote: >> On 05 Jan 2016, at 21:52, Andrea Faulds wrote: >> This is more of a side-note, but maybe it's worth bringing up. Since >> token_get_all gives an array with subarrays of a regular structure, might it

Re: [PHP-DEV] Re: [RFC] Normalize token_get_all() output (with flag)

On Tue, Jan 12, 2016 at 3:26 PM, Stanislav Malyshev wrote: >> How does this sound? >> 1. Keep the current RFC basically as is. It's a minor addition to >> token_get_all() which can be slotted into existing code to improve >> readability, but offers little advantage beyond

Re: [PHP-DEV] [RFC DISCUSSION] typeof

On Sat, Jun 4, 2016 at 5:12 AM, Fleshgrinder wrote: > I prepared my first contribution to internals: > Welcome! > https://github.com/php/php-src/pull/1932 > I've put a couple minor notes on the implementation. Nothing technically wrong, just style and micro-perf. > I

Re: [PHP-DEV] [RFC] [PRE-VOTE] Union types

On Thu, Jun 2, 2016 at 4:00 AM, Bob Weinand wrote: > I know, it has been quite some time … but it's still well in time for 7.1. > > Time to move on and put Union types to vote soon. [In the next 1-2 days] > > We have done some changes to the RFC to emphasize the appeal of

Re: [PHP-DEV] PHP's handling of BOM (byte order mark)

On Mon, May 30, 2016 at 5:40 PM, Stanislav Malyshev wrote: >> BOM's should not be treated as characters and should not be sent to >> the output. Is there any reason this should be considered the expected >> behavior? > > The reason would be PHP does not know where surrounding

Re: [PHP-DEV] PHP's handling of BOM (byte order mark)

On Mon, May 30, 2016 at 7:18 PM, Stanislav Malyshev wrote: >> In fact, the idea of stripping content from a script file isn't >> without precedent. Shebang lines are routinely removed from >> cli/cgi/fpm, and if you want to properly output it, you need to do so > > True,

Re: [PHP-DEV] Functional Interfaces RFC?

On Wed, Jun 1, 2016 at 4:28 PM, Stanislav Malyshev wrote: > The voting for https://wiki.php.net/rfc/functional-interfaces should be > finished by May 29th but it's still not closed (I presume it should be > closed as declined judging by vote results). Any objections to doing

Re: [PHP-DEV] Voting period for Callable Prototypes RFC?

On Wed, Jun 1, 2016 at 5:07 PM, Stanislav Malyshev wrote: > The vote for https://wiki.php.net/rfc/callable-types started on May > 23th, but the RFC does not have vote end date. For minimal voting period > - 1 week - if should have already ended, unless authors have the reason

[PHP-DEV] [Bug #68319] unserialize() with modified class definition.

https://bugs.php.net/bug.php?id=68319 https://3v4l.org/irnRC The crux is this: * Object instance gets serialized with one definition, maybe stored in DB/file, whatever, the serialized value lives on. * Class definition changes slightly. In this case, a property changes visibility. * Serialized

[PHP-DEV] Re: [RFC] Normalize token_get_all() output (with flag)

On Tue, Jan 5, 2016 at 11:51 AM, Sara Golemon <poll...@php.net> wrote: > On Mon, Jan 4, 2016 at 2:56 PM, Sara Golemon <poll...@php.net> wrote: >> https://wiki.php.net/rfc/token-get-always-tokens >> > A suggestion from a co-worker who's worried about seeing patt

Re: [PHP-DEV] Re: [RFC] Normalize token_get_all() output (with flag)

On Sun, Jan 17, 2016 at 3:34 AM, Stig Bakken <stig.bak...@gmail.com> wrote: > On Jan 17, 2016 05:23, "Sara Golemon" <poll...@php.net> wrote: >> >> Okay, i've got a starting point up at >> https://github.com/phplang/php-token . It's basic

Re: [PHP-DEV] Re: [RFC] Normalize token_get_all() output (with flag)

On Thu, Jan 14, 2016 at 7:59 PM, Andrea Faulds wrote: >> 2. Make a new extension to prototype this PhpToken class outside of >> the php-src tree, add all the extra goodies we want (array of token >> return, iterator of token return, extra info, limited info, etc...) >> 3. When this

Re: [PHP-DEV] Re: [RFC] Add PHP_ENGINE Constant

On Fri, Feb 5, 2016 at 8:20 AM, Pierre Joye wrote: >> I do however like the idea of feature detection - I wonder if perhaps we >> could do something where it's done at compile time and therefore minimally >> impacts runtime? > > This could be what you actually need. A #ifdef

Re: [PHP-DEV] Re: Fw: new message

On Wed, Feb 10, 2016 at 6:19 PM, Andrea Faulds wrote: > Why isn't "Sofie Vanderplaetsen" banned from the list yet? It's repeated > spam. > Because there's no response team? *hides* -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:

Re: [PHP-DEV] [RFC] Add PHP_ENGINE Constant

> I think Dan raises some interesting points, although I think zend_version() > is often used for feature detection so they try to put a zend version in > there to be helpful i.e. HHVM x.y.z === PHP a.b (feature-wise). > That's exactly why PHP_VERSION is faked in HHVM. Because that's how users

Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal

> On 02/18/2016 02:10 PM, Colin O'Dell wrote: >> >> I'd like to propose an RFC to deprecate and eventually remove the "var" >> keyword. > I'm tepidly +1 this. It's not hurting anything, but var's time has past. Let's deprecate it, and in four year's time as we're starting to talk PHP8, we can

[PHP-DEV] [RFC] Add IntlTimeZone::getWindowsID() and IntlTimeZone::getIDForWindowsID() to ext/intl

Pretty basic RFC: There's new methods in ICU 52, wrap 'em up and make 'em available. Note that despite these APIs being windows focused, they are in fact available on Linux. They're just a database lookup, essentially. https://wiki.php.net/rfc/intl.timezone.get-windows-id -Sara P.S. - Yes, tests

Re: [PHP-DEV] [RFC] Add IntlTimeZone::getWindowsID() and IntlTimeZone::getIDForWindowsID() to ext/intl

On Wed, Mar 16, 2016 at 3:20 PM, Larry Garfield wrote: > If it works on Linux just fine, why is it called Windows? Is that really > what the ICU spec says to call them, rather than something meaningful? > (That would be sad making if so.) > Because there's no "spec" as

<    2   3   4   5   6   7   8   9   10   11   >