[PHP-DEV] Test suite results on bigendian

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mostly for Dmitry After some work, I can reduce the failed tests number from 111 to 5 :) (configure --disable-all) Those seems related to new mm. => munmap() failed: [22] Invalid argument Any idea on how to debug / fix them ? Thanks, Remi P.S. I

Re: [PHP-DEV] $http_response_header

> I think that usage may have originated in PHP, actually. Eh, dunno about that... http://lists.w3.org/Archives/Public/ietf-http-wg-old/1995SepDec/0277.html for example. Even some W3C specs use "header" instead of the more accurate "header field" so it's kind of a done deal. -- S. -- PHP Inter

Re: [PHP-DEV] [RFC] IntlChar class and intl_char_*() functions

> On 28 Nov 2014, at 06:49, Stanislav Malyshev wrote: > >> If we add that, we should also have an analogue of JavaScript’s >> String.charCodeAt/String.codePointAt to do the operation in reverse. > > That'd be a bit harder since it's not clear what "at" means there - > byte? codepoint? grapheme

Re: [PHP-DEV] $http_response_header

> > Wow, I had no idea that existed; what an incredibly ugly implementation. Even > the name is weird (why "header" singular when it contains an array of > headers?) Actually, no. HTTP responses contain a single header at the protocol level, but contain multiple lines. At some point, peopl

Re: [PHP-DEV] Unable to subscribe to php.net website mailing list

On 12/1/2014 2:19 PM, Levi Morrison wrote: I suspect this is a problem on certain mirrors. That explains intermittent failures, at least. I agree that this is possibly the issue. I did eventually get signed up. I just used the "subscribe via e-mail" to ezmlm method that someone here pointed

Re: [PHP-DEV] [RFC] IntlChar class and intl_char_*() functions

On Thu, Nov 27, 2014 at 12:22 AM, Stanislav Malyshev wrote: > Looking into this and also reading the \u{} proposal, I also thought - > do we have a programmatic way of doing what \u would do? I.e. if we > assume $x holds an Unicode codepoint value (i.e., an integer) do we have > a good built-in wa

Re: [PHP-DEV] $http_response_header

On 1 December 2014 22:28:04 GMT, Ralph Schindler wrote: >Hi all, > >Many of you know from reading the subject line whats coming next! ;) > >In php, after we interact with HTTP streams (as a client), PHP conjures > >into local scope a variable with header information from the previous >request $h

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

Hi! > To get a bit philosophical: Is it really the language's job to make > that decision? Is there a difference between "encouraging", > "allowing", and "enabling"? I think, yes on both. The PHP tradition is to allow doing stuff that may look weird (most languages won't allow you to do $$foo) bu

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

Yes, C# documented here: http://msdn.microsoft.com/en-us/library/79b3xss3.aspx On Mon, Dec 1, 2014 at 5:41 PM, Levi Morrison wrote: > Perhaps I have missed it in the noise, but have any other mainstream > languages (or new hipster ones; I don't care) have something > equivalent to the proposed s

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

Perhaps I have missed it in the noise, but have any other mainstream languages (or new hipster ones; I don't care) have something equivalent to the proposed static classes? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

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

PR with this feature request: https://github.com/php/php-src/pull/929 On Mon, Dec 1, 2014 at 4:56 PM, Rowan Collins wrote: > On 1 December 2014 20:30:46 GMT, Andrea Faulds wrote: > > > > The problem is that, well, global state is rarely a good thing, I don’t > think we should be encouraging it.

[PHP-DEV] $http_response_header

Hi all, Many of you know from reading the subject line whats coming next! ;) In php, after we interact with HTTP streams (as a client), PHP conjures into local scope a variable with header information from the previous request $http_response_header. Is this behavior something we want to keep

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

On 1 December 2014 20:30:46 GMT, Andrea Faulds wrote: > > The problem is that, well, global state is rarely a good thing, I don’t think > we should be encouraging it. To get a bit philosophical: Is it really the language's job to make that decision? Is there a difference between "encouraging",

Re: [PHP-DEV] Unable to subscribe to php.net website mailing list

I suspect this is a problem on certain mirrors. That explains intermittent failures, at least. On Mon, Dec 1, 2014 at 11:44 AM, Robert Parker wrote: > I recently changed domains and email. I also had this issue for > unsubscribing my previous email and signing up this one. Tried again a few > hou

Re: [PHP-DEV] Static functions Vs Nonstatic functions

> On 1 Dec 2014, at 19:48, Carlos Rodrigues wrote: > > It it gets dropped in the future i will come back and ask to make it > possible to call a static method and normal methods with the same name :P. > For now i will just wait. Can’t be done. It’s important for inheritance that you can call me

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

> On 1 Dec 2014, at 17:46, Stanislav Malyshev wrote: > > Hi! > >> (2) Add lexically-scoped variables, and allow normal global functions >> to be closures. By this I mean we add something like JavaScript’s >> `let` keyword that would make a variable that is unset when it falls >> out of scope (e

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

Hi! > static class Foo { > function bar() { > echo do_something_with($this); > } > } > > Much nicer (and just as easy) for that to give a compile-time error of > "Static class Foo cannot contain non-static function bar" than for it to > autoload fine, and then give a less obvious

Re: [PHP-DEV] Static functions Vs Nonstatic functions

Hi, Glad to hear it was discussed. I understand you guys are busy and can't just change things out of nowhere, but i wish it will be dropped in the future. It it gets dropped in the future i will come back and ask to make it possible to call a static method and normal methods with the same name :

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

I'm working on a patch right now and I removed the implicit configuration of static to methods. It's only missing reflection magic. Should be out of the oven in one hour or less. On Mon, Dec 1, 2014 at 2:44 PM, Lars Strojny wrote: > Hi Guilherme, hi Robert. > > > On 01 Dec 2014, at 14:58, Robert

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] Static classes (Was Abstract final classes)

Hi! > (2) Add lexically-scoped variables, and allow normal global functions > to be closures. By this I mean we add something like JavaScript’s > `let` keyword that would make a variable that is unset when it falls > out of scope (end of a {} block, end of a file etc.). Then, we allow > normal fun

Re: [PHP-DEV] Static functions Vs Nonstatic functions

Hi! > class Cube { > function weird() { >echo Duck::foo(); > } > > } > > class Duck { > public function foo() { > echo 'My class is: ' . get_class($this); > } > } > > $rubik = new Cube; > $rubik->weird(); // Output: My class is: Cube This code produces: Deprecated: Non-static m

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

Levi Morrison wrote on 01/12/2014 17:58: The only thing missing is a standardised, enforced, annotation on the class to declare that you are using this ability and instances will never be created. Let's say a class has no members: what's the harm in instantiating it? Sure, it logically doesn't d

Re: [PHP-DEV] Unable to subscribe to php.net website mailing list

I recently changed domains and email. I also had this issue for unsubscribing my previous email and signing up this one. Tried again a few hours later and both worked. Robert Parker *Full Stack Developer* Phone: 360-773-0963 Twitter: @yamiko_ninja On Sun, Nov 30, 2014 at 11:44 AM, Ferenc Kovacs

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

Am 01.12.2014 17:37 schrieb "Rowan Collins" : > > guilhermebla...@gmail.com wrote on 01/12/2014 15:27: > >> (1) Function/Namespaced function autoloading >> (2) State encapsulation >> (3) Function scoping > I would add (4) static polymorphism, which Late Static Binding explicitly supports. Amen!

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

> The only thing missing is a standardised, enforced, annotation on the class > to declare that you are using this ability and instances will never be > created. Let's say a class has no members: what's the harm in instantiating it? Sure, it logically doesn't do anything useful, but is this user e

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

guilhermebla...@gmail.com wrote on 01/12/2014 15:27: (1) Function/Namespaced function autoloading (2) State encapsulation (3) Function scoping I would add (4) static polymorphism, which Late Static Binding explicitly supports. But PHP is not one of these dogmatic “everything must be a class

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

> On 1 Dec 2014, at 16:12, Christoph Becker wrote: > > Andrea Faulds wrote: > >> Yes, they’re a simple addition, but I still think they’re the wrong >> solution to the problem. We shouldn’t force people to use classes for >> simple collections of functions. People have wanted function >> autolo

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

Andrea Faulds wrote: > Yes, they’re a simple addition, but I still think they’re the wrong > solution to the problem. We shouldn’t force people to use classes for > simple collections of functions. People have wanted function > autoloading for years. I say it’s high time we add that. Maybe

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

Hi! > On 1 Dec 2014, at 15:27, guilhermebla...@gmail.com wrote: > > Hi Andrea, > > Thanks a lot for putting efforts thinking through this problem. > Indeed we have 3 problems that leads to "static classes". You detailed 2 of > them. > The third is around encapsulation. I may want functions that

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

Hi Andrea, Thanks a lot for putting efforts thinking through this problem. Indeed we have 3 problems that leads to "static classes". You detailed 2 of them. The third is around encapsulation. I may want functions that are reused by other functions at the namespace level, but that shouldn't be used

Re: [PHP-DEV] Re: PowerPC64 - test suite

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 01/12/2014 11:09, Remi Collet a écrit : > Notice: master on ppc64 seems in quite bad shape, we currently > have 111 failed tests (with ./configure --disable-all). 82 fixed 29 to work on... Remi. -BEGIN PGP SIGNATURE- Version: GnuPG v2 Com

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

Hi all! > On 1 Dec 2014, at 13:58, Robert Stoll wrote: > > I read your updated RFC: > https://wiki.php.net/rfc/abstract_final_class Hmm, I don’t like this new RFC either. Static classes in languages like C# exist because the language designers made the dogmatic decision to require everything

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

Hi Guilherme, I read your updated RFC: https://wiki.php.net/rfc/abstract_final_class IMO the RFC as such makes sense now (abstract final confusion is eliminated. In addition to turn methods implicitly into static methods, the __construct of a static class should be implicitly private as well. I

Re: [PHP-DEV] Feature: use Posix ACL for FPM socket

On Sun, Nov 30, 2014 at 8:33 PM, Ferenc Kovacs wrote: > On Sun, Nov 30, 2014 at 8:09 PM, Rowan Collins > wrote: > >> On 30/11/2014 18:06, Remi Collet wrote: >> >>> >However, I think we should stop including features in our patch >releases. I've heard a few others express similar sentiment, b

Re: [PHP-DEV] Static functions Vs Nonstatic functions

Hi Stanislav. Thank you for replying. I agree that PHP can be different from other languages, but i think you agree that a code like this just feels wrong: class Cube { function weird() { echo Duck::foo(); } } class Duck { public function foo() { echo 'My class is: ' . get_class($thi

Re: [PHP-DEV] Use zend_string* for op_array->arg_info[].name and class_name

See the updated patch: https://gist.github.com/dstogov/08b545de6bf113113f58 it can be safely applied again and simplifies inheritance code (thanks to Levi). The patch saves 60K (0.5%) of code segment, and make very slight speed improvement (visible with callgrind) All tests are passed. I think no

[PHP-DEV] Re: PowerPC64 patchs

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 27/11/2014 13:39, Gustavo Frederico Temple Pedrosa a écrit : > Hi, internals! > > There are some PRs for supports of PowerPC64 > > https://github.com/php/php-src/pull/737 > https://github.com/php/php-src/pull/919 > https://github.com/php/php-src

Re: [PHP-DEV] Re: EX(scope) removing

thanks. phpdbg was excluded in my DEBUG build (I was sure I built it, may be it was enabled it default previously...) Anyway, I enabled it now, and won't miss at least build problems. According to "make test", it would be great to make it run all the tests. For some reason "ext/opcahce" tests are

Re: [PHP-DEV] Use zend_string* for op_array->arg_info[].name and class_name

Hi Levi, I understood, that you don't see a big problems with the patch. :) According to your suggestions, It's possible to do it in this way, but it's going to be slower, because it would require additional memory allocation, but I agree that duplicating logic in the code isn't good. It must be