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

On Wed, Mar 16, 2016 at 2:58 PM, Stanislav Malyshev wrote: >> 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

Re: [PHP-DEV] Equal Null coalescing operator ??= https://github.com/php/php-src/pull/1795

On Tue, Mar 8, 2016 at 9:59 AM, Midori Kocak wrote: > > $this->request->data['comments']['user_id'] = > $this->request->data['comments']['user_id'] ?? ‘value’; > $this->request->data['comments']['user_id’] ??= ‘value’; > RFC it so there's a proper vote process, but you've got

Re: [PHP-DEV] [RFC Proposal] Null Coalesce Equal Operator

On Wed, Mar 9, 2016 at 10:14 AM, Midori Kocak wrote: > Remember my question about ??= operator? > https://wiki.php.net/rfc/null_coalesce_equal_operator > As I said before, I support this. The whole thing feels like a no-brainer in terms of implementing it. Davey mentioned on

Re: [PHP-DEV] Evaluate arguments of new for classes without constructors

On Sat, Mar 12, 2016 at 8:01 AM, Nikita Popov wrote: > class Foo {} > new Foo(print 'xyz'); > > will not print "xyz", because the arguments to "new" are not evaluated if > the class has no constructor. Conversely > I recall someone once dubbing this "The Rasmus

Re: [PHP-DEV] [RFC Proposal] Null Coalesce Equal Operator

On Wed, Mar 9, 2016 at 10:14 AM, Midori Kocak wrote: > Let me introduce my first RFC here: > https://wiki.php.net/rfc/null_coalesce_equal_operator > > I've jumped on the bandwagon by adding a second RFC related to this one: https://wiki.php.net/rfc/short_ternary_equal_operator

Re: [PHP-DEV] [RFC Proposal] Null Coalesce Equal Operator

On Thu, Mar 10, 2016 at 8:47 PM, Pierrick Charron wrote: > Just to let you know that I took the liberty to correct the title of your > RFC. It was still null coalesce equal operator :) > Ooops. Thanks :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe,

Re: [PHP-DEV] Re: [RFC] [Vote] Short Ternary Assignment Operator

Took me awhile to get back around to this problem, but this version feels okay. https://github.com/php/php-src/compare/master...sgolemon:short-ternary.coalesce It's less efficient than earlier versions, but no worse than the current `A = A ?: B` syntax (which is effectively what it does, with the

[PHP-DEV] [RFC] [Discussion] Octal overflow detection

https://wiki.php.net/rfc/octal.overload-checking Because having this expression evaluate to true makes me sad: ("\000" === "\400") -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Interpolation using ${} syntax with spaces inside the braces

I'm trying to decide just whether or not https://bugs.php.net/bug.php?id=71927 is "working as intended" as well as what the expected behavior in this situation /should/ be. https://3v4l.org/HfU1g indicates that at the very least HHVM and PHP disagree on the correct output, and testing the same

Re: [PHP-DEV] IntlCharsetDetector

On Thu, Apr 7, 2016 at 9:36 AM, Bishop Bettini wrote: > The problem is, developers are going to write code to guess character sets. > True. But they're going to put more faith in something in the standard distribution, assuming it's passed muster. > Ironically, PHPUnit attempts

[PHP-DEV] [RFC] IntlCharsetDetector

With a light push from Stas, I've decided to go ahead and put up IntlCharsetDetector for discussion. https://wiki.php.net/rfc/intl.charset-detector I'm still not personally convinced this API is trustworthy enough, but it's worth a formal discussion period at least. -Sara -- PHP Internals -

Re: [PHP-DEV] IntlCharsetDetector

On Mon, Apr 11, 2016 at 9:36 AM, Stanislav Malyshev wrote: > The point is even imperfect detection may be useful in certain > circumstances, and detector being part of ICU hints that people find it > useful enough to spend time implementing and supporting it. We should > not

Re: [PHP-DEV] [RFC] IntlCharsetDetector

On Mon, Apr 11, 2016 at 4:09 PM, Stanislav Malyshev wrote: > The API looks a bit strange - new IntlCharsetDetector($text) and then > detect(). Can't we just have detect([$text])? > I went with a direct wrapping of the underlying API because it always feels like we regret

Re: [PHP-DEV] RFC about automatic template escaping

On Sun, Mar 20, 2016 at 3:11 PM, Daniel Beardsley wrote: > I'd like to submit an RFC (with a pull request) for adding auto-escaping to > the php language. > > T_ECHO (echo, ZEND_AST_ECHO_ESCAPE node in the syntax tree. > Interesting approach, I assume an explicit `echo $foo;`

Re: [PHP-DEV] RFC about automatic template escaping

On Tue, Mar 22, 2016 at 7:43 AM, Colin O'Dell wrote: > This is a really interesting idea! However, I'm unsure whether it's wise > to bring this feature in without having the community test and validate it > first. Would it be possible to release this as an extension first

[PHP-DEV] [RFC] [Vote] Short Ternary Assignment Operator

Following on from Midori, I've moved the short-ternary assignment operator RFC into voting phase. The implementation for which will be her patch with appropriately different symbols and tests. https://wiki.php.net/rfc/short_ternary_equal_operator -Sara -- PHP Internals - PHP Runtime Development

Re: [PHP-DEV] Re: [RFC Proposal] Null Coalesce Equal Operator

Changing "equal" to "assignment" seems to have been the suggestion. I've taken that into the short-ternary version. And as a minor edit (not worth closing/reopening vote) would recommend the same for null coallesce. -Sara On Thu, Mar 24, 2016 at 8:46 AM, Midori Kocak wrote:

Re: [PHP-DEV] [RFC] [Vote] Short Ternary Assignment Operator

On Thu, Mar 24, 2016 at 9:45 AM, Nikita Popov wrote: > To clarify, as the RFC only mentions this by implication: > > unset($x); // Assume $x is undefined > $x ?:= $y; > > This will throw a notice, correct? > Yes. The equivalent short-ternary: $x = $x ?: $y; would

Re: [PHP-DEV] Add spaceship assignment operator

On Thu, Mar 24, 2016 at 10:56 AM, Bob Weinand wrote: >>$a $b; >>// same as >>$a = ($a === $b); >> > I see a problem with that … It’d be impossible to make it consistent with > is-equal comparison… > > === is already is-identical comparison. So, no symbol for

[PHP-DEV] Re: [RFC] [Vote] Short Ternary Assignment Operator

with ??=) On Thu, Mar 24, 2016 at 8:51 AM, Sara Golemon <poll...@php.net> wrote: > Following on from Midori, I've moved the short-ternary assignment > operator RFC into voting phase. > The implementation for which will be her patch with appropriately > different symbols and tests. > htt

Re: [PHP-DEV] Add spaceship assignment operator

On Thu, Mar 24, 2016 at 11:50 AM, Colin O'Dell wrote: > Would your proposal also allow ! to work? > I think you means !===, which is "not-identical assignment" (!== =) ! is just *CRAZY TALK* -Sara -- PHP Internals - PHP Runtime Development Mailing List To

Re: [PHP-DEV] Re: [RFC] [Vote] Short Ternary Assignment Operator

On Fri, Mar 25, 2016 at 6:44 AM, Nikita Popov wrote: > I don't think the current implementation is entirely correct. In particular, > it doesn't look memory-safe to me. You're doing an RW fetch on the LHS > first, then evaluate the RHS expression and then ASSIGN to the

[PHP-DEV] Re: [RFC] [Vote] Short Ternary Assignment Operator

On Thu, Mar 24, 2016 at 11:12 AM, Sara Golemon <poll...@php.net> wrote: > After some discussion (and realizing the referenced implementation > needed more work that a simple replacement of tokens), I've decided > the close this vote, work with Midori on both implementations some >

[PHP-DEV] IntlCharsetDetector

The subject of character set detection (yes, I know, a hard problem to solve) came up on SO chat, and Niki noticed that we don't yet wrap the ICU UCharsetDetector API so I volunteered to put something together. https://github.com/php/php-src/compare/master...sgolemon:intl.charsetdetector The

[PHP-DEV] [VOTE] IntlTimeZone::getWindowsID() and getIDForWindowsID()

Opening vote on https://wiki.php.net/rfc/intl.timezone.get-windows-id#vote at 2016-04-01 01:37 UTC. Vote will close in two weeks: 2016-04-15 23:59 UTC -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Copy On Write and Assign By Reference perform different on PHP5 and PHP7

On Thu, Mar 31, 2016 at 9:47 AM, Huqiu Liao wrote: > I have a question about Assign By Reference and I posted on StackOverflow, > I'd like to know the reason behind it, and I did not get any this kind of > answer, can anyone give me some clues. > Are you asking out of

Re: [PHP-DEV] [VOTE] IntlTimeZone::getWindowsID() and getIDForWindowsID()

On Mon, Apr 4, 2016 at 2:52 AM, Derick Rethans wrote: >> https://wiki.php.net/rfc/intl.timezone.get-windows-id#vote at > > I think the RFC misses that either mapping might not work, and hence can > not always return a string. The code handles it correctly by returning > false

Re: [PHP-DEV] [RFC:generics]

On Wed, Apr 20, 2016 at 12:17 PM, Dominic Grostate wrote: > The preferred keywords appear to be either "as" or "instanceof". > > class Foo {} > class Foo {} > > We would like to know for sure then if everyone is largely against the > addition of an "is" keyword, in

Re: [PHP-DEV] [RFC] Pipe Operator

On Sat, Apr 30, 2016 at 11:41 AM, wrote: > God I hate crap software ... TRYING to reply without top post ... but Samsung > is incapable! > > What I was trying to comment on was that trapping that no result is returned > may be what is needed, so handling the empty array

Re: [PHP-DEV] Inline functions

On Thu, Apr 28, 2016 at 1:21 AM, Dominic Grostate wrote: > As I understand it, the process by which the call stack is updated and > scope changed, is quite expensive. And from tests I can see that function > calls do actually add a not insignificant overhead to

Re: [PHP-DEV] [RFC] IntlCharsetDetector

On Tue, Apr 26, 2016 at 2:06 AM, Yasuo Ohgaki wrote: > Things might have been changed, but as you've mentioned encoding > detection is unstable and ICU is poor compared to mbstring's detection > at least for Japanese encodings. > For me, the difference is that I expect further

Re: [PHP-DEV] [RFC] PHP Attributes

On Thu, Apr 21, 2016 at 2:13 PM, Dmitry Stogov wrote: > I would like to present an RFC proposing support for native annotation. > I'm trying to imagine where the benefit of non-constant expressions comes in. <> Assuming we roll in php-ast at the same time (which is

Re: [PHP-DEV] Do symbol references always go through a hash table?

On Tue, May 17, 2016 at 9:10 PM, Jesse Schalken <m...@jesseschalken.com> wrote: > On Wed, May 18, 2016 at 1:06 PM, Sara Golemon <poll...@php.net> wrote: >> >> Yes, but that doesn't mean you should micro-optimize around it. Just >> write code that's easy to main

Re: [PHP-DEV] [RFC] Pipe Operator

On Thu, May 12, 2016 at 5:33 AM, Quim Calpe wrote: > Is $0 being considered? It's not ideal but is used as "pattern match > reference" in preg_replace, so we have a (sort of) precedent here. Same for > $1 (first capturing subpattern). > I don't believe it's been brought up yet,

Re: [PHP-DEV] [RFC] Pipe Operator

On Thu, May 12, 2016 at 5:48 AM, Zeev Suraski wrote: > Whether it's $$ or !# or $0 or any other random symbol doesn't really matter. > Agreed. > Here we have a completely optional syntactic sugar, > that's not nearly as widely useful as OOP or namespaces. > Very few things will be

[PHP-DEV] [RFC] [Discussion] Third-party editing of RFCs

https://wiki.php.net/rfc/rfc.third-party-editing Let's make RFCs more useful before AND after voting! -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [RFC] Pipe Operator

On Fri, Apr 29, 2016 at 12:58 PM, Sara Golemon <poll...@php.net> wrote: > This is one of my favorites out of HackLang. It's pure syntactic > sugar, but it goes a long way towards improving readability. > https://wiki.php.net/rfc/pipe-operator > I've added a summary (as best

Re: [PHP-DEV] [RFC] Pipe Operator

On Tue, May 17, 2016 at 4:14 AM, Rowan Collins wrote: > On 17/05/2016 11:55, Jesse Schalken wrote: > $id > |> StringList::decode($$) > |> array_replace($$, $replace) > |> StringList::encode($$) > |> $id; > > > Sara, what do you think of this tweak, and my

Re: [PHP-DEV] [RFC] Pipe Operator

On Tue, May 17, 2016 at 5:47 AM, Ryan Pallas wrote: > Can the place holder be used twice? > In the current PR version, no. It adds complexity to the implementation when dealing with temp vars. In the interest of keeping the implementation simple, I opted for making the

Re: [PHP-DEV] [RFC] Pipe Operator

On Mon, May 16, 2016 at 2:17 AM, François Laupretre wrote: > Le 16/05/2016 à 03:33, Larry Garfield a écrit : >> This still sounds awfully complicated to me. I would far, far prefer >> the $$ syntax to special casing function aliases just to dance around >> it. If we had a

Re: [PHP-DEV] [RFC] Pipe Operator

On Sat, May 14, 2016 at 3:33 AM, François Laupretre wrote: > Le 14/05/2016 à 01:36, Simon Welsh a écrit : \>> Sure, you could try to use the type of the value being passed in, >> but that ends up much more magic and then you run into the same >> problem with strpos, or

Re: [PHP-DEV] [RFC][VOTE] Closure from callable

On Sun, May 15, 2016 at 11:20 AM, Nikita Nefedov wrote: > why would you need to support a $this->fieldName case though? > Because to not support it would be to deliberately design in a new flavor of inconsistency into the language. $obj->memb is a property access in PHP.

Re: [PHP-DEV] [RFC] [Discussion] Third-party editing of RFCs

On Thu, May 12, 2016 at 4:37 PM, Stanislav Malyshev wrote: >> https://wiki.php.net/rfc/rfc.third-party-editing >> >> Let's make RFCs more useful before AND after voting! > > I like the idea, though I would suggest some limit on how big each > argument should be (maybe

Re: [PHP-DEV] [RFC] [Discussion] Third-party editing of RFCs

On Fri, May 13, 2016 at 1:56 PM, Joe Watkins wrote: > Still, I regard editing someone else's work as poor form. > > Introducing a way to do that, and relying on social pressure to keep > everyone in check is not a good long term plan ... sounds great, until >

Re: [PHP-DEV] Do symbol references always go through a hash table?

On Tue, May 17, 2016 at 7:51 PM, Jesse Schalken wrote: > Does that mean a function which accepts an instance of an interface and > calls a method on it will have to do a full lookup of the method whenever > the concrete class isn't the same as when that function was first

Re: [PHP-DEV] [RFC] [Discussion] Third-party editing of RFCs

On Fri, May 13, 2016 at 7:26 AM, François Laupretre wrote: > Le 13/05/2016 à 15:30, Rowan Collins a écrit : >> >> If somebody adds something that is genuinely irrelevant (e.g. based on a >> simple misunderstanding of the RFC) then somebody else (*anyobdy* else) >> could remove

Re: [PHP-DEV] [RFC] Pipe Operator

On Fri, May 13, 2016 at 10:18 AM, François Laupretre wrote: >> So we'd have to audit all 4k+ functions in the PHP runtime (and >> provide a mechanism for defining it on userspace functions)? > > That's right, except that, if we only consider functions accepting more than > 1

Re: [PHP-DEV] [RFC] Pipe Operator

On Thu, May 12, 2016 at 11:52 AM, François Laupretre wrote: > If we restrict usage to function calls, we can quite easily get rid of the $$ > by > associating to each function the position where the lhs must be inserted > when used as a 'piped function call'. > So we'd have to

Re: [PHP-DEV] [RFC] [Discussion] Third-party editing of RFCs

On Thu, May 12, 2016 at 1:32 PM, Robert Williams wrote: > It reminds me of the election pamphlets that my state sends > out to inform voters of what the upcoming ballet measures are and what > various folks’ for/against arguments are. > I was literally looking at said

[PHP-DEV] [RFC] Pipe Operator

This is one of my favorites out of HackLang. It's pure syntactic sugar, but it goes a long way towards improving readability. https://wiki.php.net/rfc/pipe-operator -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [RFC] [VOTE] Octal Interpolation Overflow

Voting has opened for https://wiki.php.net/rfc/octal.overload-checking Vote YES to raise a compile time warning when octal values greater than \377 are used. Vote NO to continue ignoring the overflow. Regardless of outcome, the value interpolated into the string will retain "wrap-around"

Re: [PHP-DEV] [RFC] Pipe Operator

On Tue, May 3, 2016 at 11:52 AM, Fleshgrinder <p...@fleshgrinder.com> wrote: > On 5/3/2016 8:45 PM, Sara Golemon wrote: >> Pretending that poorly designed libraries exist is naîve. >> > I really do not know what you want to tell me with that first sentence. > Ooops, mis

Re: [PHP-DEV] [RFC] Pipe Operator

On Tue, May 3, 2016 at 11:36 AM, Fleshgrinder <p...@fleshgrinder.com> wrote: > On 5/3/2016 8:12 PM, Sara Golemon wrote: >> The difference with scalar objects is: >> A) We need to agree on what methods these objects are going to have. >> ((And we won't agree)) >> &

Re: [PHP-DEV] [RFC] Pipe Operator

On Tue, May 3, 2016 at 9:30 AM, Fleshgrinder wrote: > On 5/3/2016 4:53 AM, Terry Cullen wrote: >> Doesn't Nikic's scalar objects (https://github.com/nikic/scalar_objects) >> more or less achieve the same thing while also cleaning up the std lib? >> >> $ret = scandir($arg)

Re: [PHP-DEV] [RFC] Pipe Operator

On Tue, May 3, 2016 at 11:29 AM, Lester Caine wrote: > Which does beg the question ... "Just how many problem spaces are > currently under discussion?" ... There is a space for some additional > extensions that provided experimental solutions to some of the perceived >

Re: [PHP-DEV] [RFC] Pipe Operator

On Mon, May 2, 2016 at 5:57 PM, Stephen Coakley wrote: > Could you use a closure instead to accomplish this? (Again yes, Sara could > you clarify if this is permitted?) > > $ret = scandir($arg) > |> array_filter($$, function($x) { return $x !== '.' && $x != '..';

Re: [PHP-DEV] [RFC] Pipe Operator

On Mon, May 2, 2016 at 12:56 AM, Michael Wallner <m...@php.net> wrote: > On 30/04/16 20:57, Sara Golemon wrote: >> What follows is a terrible idea and I don't mean to propose it as a >> solution, but to spark further conversation: >> >> $result = getData() >

Re: [PHP-DEV] Interpolation using ${} syntax with spaces inside the braces

On Thu, Apr 14, 2016 at 3:37 AM, Davey Shafik wrote: > Whitespace inside of { } should not matter, the contents should be evaluated > as an expression and it's results used to determine the variable name, so > ${great} should also be $my as in the other cases. > Right. Which is

[PHP-DEV] Re: [RFC] [Discussion] Octal overflow detection

On Tue, Apr 12, 2016 at 7:38 PM, Sara Golemon <poll...@php.net> wrote: > https://wiki.php.net/rfc/octal.overload-checking > Because having this expression evaluate to true makes me sad: ("\000" > === "\400") > I haven't heard any responses on this and wan

Re: [PHP-DEV] RFC: Functional Interfaces

On Mon, Apr 18, 2016 at 12:17 PM, Stanislav Malyshev wrote: > Hi! > >> Please review the following RFC: >> https://wiki.php.net/rfc/functional-interfaces >> An implementation is provided, and is testable on 3v4l. > > This looks like a rather narrow case already

Re: [PHP-DEV] [RFC:generics]

On Tue, Apr 19, 2016 at 7:54 PM, guilhermebla...@gmail.com wrote: > 1- Even though mentioned, I'd still use "extends" or "implements" instead of > "is" (which would be a new pseudo-reserved keyword) to enforce data type > consistency and prevent developers to

Re: [PHP-DEV] [RFC:generics]

On Tue, Apr 19, 2016 at 7:56 PM, Jesse Schalken wrote: >> class Collection {... > > I think the "where T is Traversable, T is Countable" syntax was intended to > represent the intersection (i.e. a "Countable Traversable"), not the union. > > So you would need an

Re: [PHP-DEV] [RFC:generics]

On Tue, Apr 19, 2016 at 4:13 PM, Stanislav Malyshev wrote: >> class Collection {... > > I am sorry if this sounds harsh, but I really hope we won't have > something like this in PHP. Java templates are complex and weird enough, > adding another layer on top of that to allow

Re: [PHP-DEV] [RFC:generics]

On Tue, Apr 19, 2016 at 1:16 PM, Mathieu Rochette wrote: > about the upper bounds, have you consider another way of describing the > constraints, eg: > > class Box where T is Boxable > > this would allow multiple constraints, eg: > > class Collection where T is Traversable,

Re: [PHP-DEV] [RFC] Pipe Operator

On Sun, May 8, 2016 at 10:37 PM, Stanislav Malyshev wrote: > I don't see how it helps anything. It just replaces clear variable names > with cryptic sequences of characters with no intuitive meaning and magic > semantics invented solely to save a few keystrokes. > Yep, that's

Re: [PHP-DEV] [RFC] Pipe Operator

On Sun, May 8, 2016 at 11:45 PM, Stanislav Malyshev wrote: >> Yep, that's exactly what "->" does. It's just pointless syntactic > > No, not really. Calling method on an object is an universally accepted > phrase in many languages. > I never said it wasn't. I said it was

Re: [PHP-DEV] Pipe Operator v2

On Sat, Jul 23, 2016 at 4:15 AM, Rasmus Schultz wrote: > FWIW, I've read the manual page for the Hack page, and the RFC, a couple of > times now, and I simply don't understand it. > Perhaps the documentation needs clarifying then. > Are most PHP developers going to understand

Re: [PHP-DEV] Pipe Operator v2

On Sat, Jul 23, 2016 at 1:11 PM, Stanislav Malyshev wrote: > There is a lot of ways in which PHP needs improvement, but right now I > think inventing more syntax tricks in not one of them. Even in syntax > department, PHP has areas where we could use improvement (e.g. to name

Re: [PHP-DEV] Pipe Operator v2

On Sat, Jul 23, 2016 at 8:15 AM, Rowan Collins wrote: > Glad it makes sense. :) I realise "return $$" would have to have some > special handling, but it would feel more natural to me. I guess the only > concern is what happens when a pipeline has a return terminal and is

Re: [PHP-DEV] Pipe Operator v2

On Thu, Jul 21, 2016 at 6:59 AM, Rowan Collins <rowan.coll...@gmail.com> wrote: > On 21/07/2016 00:42, Sara Golemon wrote: >> >> With the branching of 7.1, and after some reflection on the previous >> feedback, I'd like to reopen discussion of the Pipe Operator RFC >&

Re: [PHP-DEV] Pipe Operator v2

On Thu, Jul 21, 2016 at 2:56 PM, Rowan Collins <rowan.coll...@gmail.com> wrote: > On 21/07/2016 22:28, Sara Golemon wrote: >> >> Are you picturing the return statement returning from the current >> function? Or "returning" from the current pipe chain? >&g

Re: [PHP-DEV] Method compare()

On Tue, Aug 9, 2016 at 10:33 AM, David Rodrigues wrote: > Currently PHP has a method called "version_compare()". Should be great > if we have the same function but to general usage. There are some > implementations on web for that, but I guess that it could be done >

[PHP-DEV] Pipe Operator v2

With the branching of 7.1, and after some reflection on the previous feedback, I'd like to reopen discussion of the Pipe Operator RFC https://wiki.php.net/rfc/pipe-operator which I had previously put on hold. I've changed much of the argument wording of the proposal, but not the substantive

Re: [PHP-DEV] Pipe Operator v2

> On Thu, Jul 21, 2016 at 9:05 AM, Thomas Bley wrote: > to me this code is perfectly readable and static code analysis is only > complaining about missing semicolons at the end of the lines and short > variable names: > > $x = loadConfig(); > $x = buildDic($x); > $x =

Re: [PHP-DEV] Pipe Operator v2

On Wed, Jul 20, 2016 at 8:50 PM, Larry Garfield wrote: > I am still generally in favor of this proposal. Especially when dealing > with nested array functions this operator would be a big boon to > readability. > That's honestly my 90% use-case as well. array_merge and

Re: [PHP-DEV] Tracing exit()

On Thu, Aug 4, 2016 at 11:10 AM, Bishop Bettini wrote: > I'm wondering if the shutdown functions could access telemetry: > > register_shutdown_function(function () { > > $context = shutdown_get_context(); > > /** array ( 'exit' => array ('file' => '/path/to/Foo.php',

Re: [PHP-DEV] Function auto-loading

On Mon, Aug 8, 2016 at 9:59 PM, Lester Caine wrote: >> That is, when I'm running the test-suite of my package, the Composer >> project is the root folder of that package - but when the package is >> being consumed by another project, it's installed in a sub-folder in >> that

Re: [PHP-DEV] RFC Posted for str_begins and str_ends functions

On Mon, Aug 1, 2016 at 3:52 PM, wrote: > I recently emailed the group about submitting an RFC for str_begins() and > str_ends() functions. The RFC has now been officially submitted and is > viewable at: > > https://wiki.php.net/rfc/add_str_begin_and_end_functions > Feeling

Re: [PHP-DEV] [RFC] Iterable

On Sun, Jul 3, 2016 at 9:50 AM, Aaron Piotrowski wrote: >> Do you mean that this code: >> >> $a = json_decode('{"a": 1, "b": 2, "c": 3}'); >> foreach($a as $b) { >>var_dump($b); >> } >> >> will no longer work, or that it will still work, but stdClass would not >> be

[PHP-DEV] [RFC][Accepted] HashContext as Object

Voting on https://wiki.php.net/rfc/hash-context.as-resource has closed. The RFC has passed 15 to 0. Implementation specific selection: Frozen (9-6) I'll merge the diff later tonight or tomorrow. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:

Re: [PHP-DEV] Namespaces in Core

On Tue, Feb 7, 2017 at 6:59 PM, Dan Ackroyd wrote: > On 7 February 2017 at 17:56, Scott Arciszewski wrote: >> I'm taking all the No votes spawned by this thread to mean "we >> don't want namespaced functions ever". > > That would be a bad assumption.

Re: [PHP-DEV] Namespaces in Core

On Mon, Feb 6, 2017 at 12:21 PM, Fleshgrinder wrote: > First: I like namespaces in Core but here me out! > > The PHP (case does not matter) would be the proper vendor name to put > Core stuff in, as far as I remember it is also reserved for PHP > functionality. There were

Re: [PHP-DEV] Namespaces in Core

On Mon, Feb 6, 2017 at 3:47 PM, Nikita Popov wrote: > I'm strongly against use of the PHP namespace as a blanket namespace for > bundled PHP extensions. The PHP namespace should be used only for > functionality that is actually in some way related to PHP. For example, the >

[PHP-DEV] Fix for invalid declare(ticks=expr); values

A crash report came into security@ (which needn't have been private) about a segfault in response to trying to compile clearly broken code. https://github.com/php/php-src/pull/2395 is a fix for this, but before I merge it (and check how far back it goes -- my suspicion is 7.0), I'm hoping for some

Re: [PHP-DEV] Improve (disable|enable)_functions #65386

On Fri, Feb 10, 2017 at 4:02 AM, Ben RUBSON <ben.rub...@gmail.com> wrote: >> On 09 Feb 2017, at 18:12, Sara Golemon <poll...@php.net> wrote: >> Could you clarify? `disable_functions` *IS* a PHP_INI_SYSTEM directive: >> >> PHP_INI_ENTRY("disable_function

Re: [PHP-DEV] Improve (disable|enable)_functions #65386

On Fri, Feb 10, 2017 at 4:09 PM, Ben RUBSON wrote: > I was talking more specifically about the following : > "php_admin_value disable_functions mydisfunction" > phpinfo() shows mydisfunction as locally disabled, > but in reality can still be used. > Uh... that sounds like a

Re: [PHP-DEV] Improve (disable|enable)_functions #65386

On Thu, Jan 19, 2017 at 6:18 AM, Ben RUBSON wrote: > As proposed by cmb (thank you !), I open a discussion regarding req #65386 : > https://bugs.php.net/bug.php?id=65386 > > It summarizes requests around disable_functions directive : > - modification of disable_functions to

[PHP-DEV] [RFC][Vote] HashContext using Objects

Voting has opened on: https://wiki.php.net/rfc/hash-context.as-resource Voting will remain open for two weeks and will close on 31 Jan, 2017 at 23:59:59 UTC -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Wiki - Extentions

On Thu, Nov 3, 2016 at 4:50 PM, Daniel Klein wrote: > The page https://wiki.php.net/internals/extensions has some spelling > mistakes and things that could be clearer. > > The heading: "Registering *additionnal *extensions from the SAPI module" > should be spelt

Re: [PHP-DEV] [RFC] OpenSSL BigNum support

On Sun, Oct 23, 2016 at 5:06 PM, Stanislav Malyshev wrote: >> What are the specific reasons for choosing OpenSSL Bignums over GMP, >> outside of extension availability (which is totally a path I don't want us >> to go down -- see also recent attempts to duplicate ext/mbstring

[PHP-DEV] [RFC] OpenSSL BigNum support

As it says on the tin: Wrap the BN (BigNumber) library in OpenSSL. https://wiki.php.net/rfc/openssl.bignum -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] OpenSSL BigNum support

> Looks ok to me. Would probably not hurt also add tests for various error > conditions. > There's one TypeError test in there, but I can easily add more. (And probably will on my flight tomorrow.) > I realise this is only exposing functionality already available with > OpenSSL but is it worth

Re: [PHP-DEV] [RFC] OpenSSL BigNum support

On Mon, Oct 17, 2016 at 11:41 PM, Sebastian Bergmann <sebast...@php.net> wrote: > Am 18.10.2016 um 08:23 schrieb Sara Golemon: >> I'm mostly curious about thoughts on API decisions. > > * public static function createFromBinary(string $number): BigNum; > * public static fu

Re: [PHP-DEV] [RFC] Deprecate and remove INTL_IDNA_VARIANT_2003

On Sat, Jan 7, 2017 at 6:06 AM, Christoph M. Becker wrote: > Following up on , I have > written the RFC > > > > and hereby placing it under discussion. > > I

[PHP-DEV] Fwd: [RFC] HashContext as Object

On Mon, Dec 26, 2016 at 7:35 PM, Sara Golemon wrote: > I was trawling through Pull Requests and found #660 which I think is a > nice idea and deserves some attention. It involves minor BC however, > so I've updated the patch and presented it for your discussing > pleasure. >

[PHP-DEV] Re: [PHP-CVS] com php-src: Use new param API in standard: ext/standard/browscap.c ext/standard/cyr_convert.c ext/standard/datetime.c ext/standard/dl.c ext/standard/dns.c ext/standard/fsock.c

On Sun, Jan 1, 2017 at 4:51 AM, Christoph M. Becker wrote: > On 01.01.2017 at 13:36, Derick Rethans wrote: >> I thought the idea was to only for this for functions that would be called >> often as the win is so little? > > The performance improvement can be considerable[1],

Re: [PHP-DEV] Introduction to the PHP source code

On 29/12/16 16:17, ilija.tov...@me.com wrote: > Looking at the giant repository I feel a little overwhelmed. Is there a > place where I can get started and learn more about the architecture of the > interpreter before diving into the source code itself? I’m sorry if this > question has been asked

[PHP-DEV] Fwd: [RFC] HashContext as Object

On Thu, Dec 29, 2016 at 6:32 PM, Sara Golemon <poll...@php.net> wrote: > On Mon, Dec 26, 2016 at 7:35 PM, Sara Golemon wrote: >> I was trawling through Pull Requests and found #660 which I think is a >> nice idea and deserves some attention. It involves minor BC howeve

Re: [PHP-DEV] Re: Mailing Lists and URLs Causing Rejections

On Mon, Jan 9, 2017 at 11:56 PM, Ferenc Kovacs wrote: > On Tue, Jan 10, 2017 at 4:21 AM, Ferenc Kovacs wrote: >> yeah, unfortunatelly ecelerity is a bit of a black box, here is the >> relevant config: >> If only someone on systems@ knew anything about

[PHP-DEV] [RFC] HashContext as Object

I was trawling through Pull Requests and found #660 which I think is a nice idea and deserves some attention. It involves minor BC however, so I've updated the patch and presented it for your discussing pleasure. https://wiki.php.net/rfc/hash-context.as-resource -Sara -- PHP Internals - PHP

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