[PHP-DEV] Re:[PHP] PHP 5.4.6RC1 Released for Testing!

when your do php x64 version? or tell me how i do it. -- Original -- From: "Stas Malyshev"; Date: Fri, Aug 3, 2012 11:48 AM To: "PHP Internals"; "php-gene...@lists.php.net"; Subject: [PHP] PHP 5.4.6RC1 Released for Testing! Hi! I've released PHP 5.4.6RC

Re: [PHP-DEV] xml ext and & entities

Hi! > Can you try using a stock version of libxml or using the latest version? > > I met some issues in the past on Centos because of bad patches applied > to libxml. I've built both 2.7.8 and 2.8.0 from source - same result. & is ignored when parsing with PHP xml extension. -- Stanislav Malysh

Re: [PHP-DEV] [RFC] Remove calls with incompatible Context

Hi! > https://wiki.php.net/rfc/incompat_ctx > > An RFC for deprecating and removing $this from incompatible context. IMO makes sense. Nulling-out $this makes most of the sane code (like de-facto static functions not marked as static) work, and breaking insane code in 5.5 in acceptable. -- Stani

[PHP-DEV] PHP 5.4.6RC1 Released for Testing!

Hi! I've released PHP 5.4.6RC1 which can be found here: http://downloads.php.net/stas/ Windows binaries as always are at: http://windows.php.net/qa/ This is a regular bugfix release, the full list of issues fixed can be found in the NEWS files. Please test and report if anything is broken

Re: [PHP-DEV] Add runkit to PHP Runtime

On Fri, Aug 3, 2012 at 5:46 AM, Sherif Ramadan wrote: > > > > I don't see why this is not a good programming practice, lets get the > > following example: > > class Member { > > public static function create(...) { } > > public function update(...) { } > > public function remove(...) {

Re: [PHP-DEV] Add runkit to PHP Runtime

On Aug 2, 2012, at 17:16, Ángel González wrote: > On 03/08/12 01:22, Sara Golemon wrote: >> In all seriousness, I'd love to hear how you'd do Sandboxing without >> using the tsrm context hack I used in runkit. That approach had >> nothing to do with being in PECL, it had to do with that being th

Re: [PHP-DEV] Add runkit to PHP Runtime

> For my vote: I think keeping this in pecl is fine, because they're all > things which can be done from the extension space. If my vote still counts (I was somehow involved in the creation of runkit at one point (-: ), I say the same: extension is fine. Don't monkeypatch production. S

Re: [PHP-DEV] Add runkit to PHP Runtime

> > I don't see why this is not a good programming practice, lets get the > following example: > class Member { > public static function create(...) { } > public function update(...) { } > public function remove(...) { } > // ... > } > > now you wish to add, for example, a ban funct

Re: [PHP-DEV] PHP 5.x Documentend End Of Life Dates

On 2 August 2012 16:58, Adam Harvey wrote: > On 2 August 2012 16:51, Morgan L. Owens wrote: >> On 2012-08-02 20:42, Peter Cowburn wrote: >>> The details on things being "obsoleted" should be in the migration guides. >>> >> Then that would be where the links go, in a similar manner to the Changelo

Re: [PHP-DEV] Add runkit to PHP Runtime

On Fri, Aug 3, 2012 at 3:07 AM, Anthony Ferrara wrote: > Yahav, > > > On Thu, Aug 2, 2012 at 7:26 PM, Yahav Gindi Bar wrote: > >> I do think that some of the runkit features should not be included in PHP >> core but I wish to focus on extending classes with extension methods, >> constants, trait

Re: [PHP-DEV] Add runkit to PHP Runtime

On 03/08/12 01:22, Sara Golemon wrote: > In all seriousness, I'd love to hear how you'd do Sandboxing without > using the tsrm context hack I used in runkit. That approach had > nothing to do with being in PECL, it had to do with that being the > only mechanism available to swap globals in and out

Re: [PHP-DEV] Add runkit to PHP Runtime

Yahav, On Thu, Aug 2, 2012 at 7:26 PM, Yahav Gindi Bar wrote: > I do think that some of the runkit features should not be included in PHP > core but I wish to focus on extending classes with extension methods, > constants, traits and members. > > Just like all other complicated and powerful fea

Re: [PHP-DEV] Add runkit to PHP Runtime

I do think that some of the runkit features should not be included in PHP core but I wish to focus on extending classes with extension methods, constants, traits and members. Just like all other complicated and powerful features in PHP, one should use them with a good reason and when he/she knows

Re: [PHP-DEV] Add runkit to PHP Runtime

On Thu, Aug 2, 2012 at 4:17 PM, Leigh wrote: >> Sandboxing: Complicated by the fact that it only works in a threaded >> build, can't transfer all types (e.g. resource, complex objects), and >> can't run concurrently. Until/unless these problems can be >> meaningfully solved, I wouldn't consider i

Re: [PHP-DEV] Add runkit to PHP Runtime

> Sandboxing: Complicated by the fact that it only works in a threaded > build, can't transfer all types (e.g. resource, complex objects), and > can't run concurrently. Until/unless these problems can be > meaningfully solved, I wouldn't consider it a functional > implementation. To me the "threa

Re: [PHP-DEV] Add runkit to PHP Runtime

"For all those things you probably shouldn't have been doing anyway" That description is on the package because you... probably shouldn't be doing these things. Further, any discussion of runkit should focus on individual features of it. Custom Superglobals: I consider these fairly harmle

Re: [PHP-DEV] Implicit isset in ternary operator

2012/8/2 Andrew Faulds : > Hi, > > Also in JavaScript if in strict mode. Legacy non-strict mode JS doesn't cause > an error though. > > JS's || operator supresses this error though, which is great for e.g. x = x > || new Object(); Could be cool to make this in PHP with the 'or' operator (or not

Re: [PHP-DEV] Add runkit to PHP Runtime

This is a great idea (the runkit, not the rootkit). On Thu, Aug 2, 2012 at 1:12 PM, Kris Craig wrote: > > > > What do you think? > > > > I think I need to get my lens prescription updated. I thought the subject > line read, "Add *rootkit *to PHP Runtime" and was already sharpening my > pitchfor

Re: [PHP-DEV] Add runkit to PHP Runtime

> > What do you think? > I think I need to get my lens prescription updated. I thought the subject line read, "Add *rootkit *to PHP Runtime" and was already sharpening my pitchfork before I realized my error. For the record, I am firmly opposed to adding a rootkit to the PHP runtime. A runkit s

Re: [PHP-DEV] Add runkit to PHP Runtime

On Thu, Aug 2, 2012 at 7:56 PM, Leigh wrote: > > On Aug 2, 2012 5:44 PM, "Yahav Gindi Bar" wrote: > > > > Hi, > > > > I don't know how to tag this kind of discussion (because it's not RFC > > request). > > I've interested in runkit PECL extension and think that it should be part > > of the PHP c

Re: [PHP-DEV] Add runkit to PHP Runtime

On Aug 2, 2012 5:44 PM, "Yahav Gindi Bar" wrote: > > Hi, > > I don't know how to tag this kind of discussion (because it's not RFC > request). > I've interested in runkit PECL extension and think that it should be part > of the PHP core runtime. > > I do think that the implementation should be dif

[PHP-DEV] Add runkit to PHP Runtime

Hi, I don't know how to tag this kind of discussion (because it's not RFC request). I've interested in runkit PECL extension and think that it should be part of the PHP core runtime. I do think that the implementation should be different and don't mind to suggest my implementation as RFC, but fir

Re: [PHP-DEV] register_globals work arounds

Em 2012-08-02 18:07, Lester Caine escreveu: [...] In the meantime some links to this old material would be helpful, if only to get access to them on the migration guides. Because I'm actively looking, hopefully the problem will not arise, but you can guarantee something will pop up that has bee

Re: [PHP-DEV] [RFC] Remove calls with incompatible Context

Em 2012-07-31 1:55, Christopher Jones escreveu: On 07/30/2012 01:32 PM, Gustavo Lopes wrote: 3. There are other low-cost alternatives, namely the obvious one: pass the object via an extra parameter instead of operating on $this directly and unconditionally. This is really easy to do. This ki

Re: [PHP-DEV] register_globals work arounds

Anthony Ferrara wrote: I'm specifically asking in relation to helping users migrate from PHP5.2 ... trying to expand the documentation of making that process easier. Pointing at a single manual page is a good example of why we need a more consistent support for all those users who

Re: [PHP-DEV] register_globals work arounds

On 02/08/2012 15:56, Ferenc Kovacs wrote: On Thu, Aug 2, 2012 at 2:34 PM, rich gray > wrote: On 02/08/2012 13:51, Lester Caine wrote: OK IMO - this should be posted on PHP general not internals -- have you tried extract() ? http://fr2.php.

Re: [PHP-DEV] register_globals work arounds

On Thu, Aug 2, 2012 at 2:34 PM, rich gray wrote: > > On 02/08/2012 13:51, Lester Caine wrote: > >> OK >> >> No discussions on why register_globals has been removed we all understand >> why and now have to live with that ... I'm not winging here! >> >> The question is "Does anybody have an 'elegan

Re: [PHP-DEV] register_globals work arounds

Lester, On Thu, Aug 2, 2012 at 8:49 AM, Lester Caine wrote: > rich gray wrote: > >> OK >>> >>> No discussions on why register_globals has been removed we all >>> understand why >>> and now have to live with that ... I'm not winging here! >>> >>> The question is "Does anybody have an 'elegant' fi

Re: [PHP-DEV] register_globals work arounds

rich gray wrote: OK No discussions on why register_globals has been removed we all understand why and now have to live with that ... I'm not winging here! The question is "Does anybody have an 'elegant' fix to quickly update a legacy site that relies on globals to pass variables between page vi

Re: [PHP-DEV] register_globals work arounds

On 02/08/2012 13:51, Lester Caine wrote: OK No discussions on why register_globals has been removed we all understand why and now have to live with that ... I'm not winging here! The question is "Does anybody have an 'elegant' fix to quickly update a legacy site that relies on globals to pa

[PHP-DEV] register_globals work arounds

OK No discussions on why register_globals has been removed we all understand why and now have to live with that ... I'm not winging here! The question is "Does anybody have an 'elegant' fix to quickly update a legacy site that relies on globals to pass variables between page views?" My origin

Re: [PHP-DEV] Implicit isset in ternary operator

Hi, Also in JavaScript if in strict mode. Legacy non-strict mode JS doesn't cause an error though. JS's || operator supresses this error though, which is great for e.g. x = x || new Object(); -- Sent from Samsung Mobile Andrew Faulds http://ajf.me/ Stas Malyshev wrote: Hi! > I've looked a

Re: [PHP-DEV] Bringing users along ...

Andrew Faulds wrote: Hmm, in that case, why do ini defaults differ significantly from those compiled in? There was a discussion about that not long ago? Aren't the PHP5.4 bits now all tidied so that the defaults match a production .ini file? So only development changes something? I've not ch

Re: [PHP-DEV] Bringing users along ...

Hmm, in that case, why do ini defaults differ significantly from those compiled in? -- Sent from Samsung Mobile Andrew Faulds http://ajf.me/ Johannes Schlüter wrote: On Wed, 2012-08-01 at 13:38 +0100, Lester Caine wrote: > The default if it's not included in the .ini is ON, but the > sample .i

Re: [PHP-DEV] PHP 5.x Documentend End Of Life Dates

> No date for 5.3 yet. Depends how development goes on the next version > after 5.4. EOL announcements are in the release announcements. 5.2 EOL > was announced here: http://www.php.net/archive/2010.php#id2010-07-22-1 Yes, I've seen that with release announcements often (but not always) a (more

Re: [PHP-DEV] PHP 5.x Documentend End Of Life Dates

> I've added http://php.net/eol Thank you. For PHP 5.x I had created a blog post which is not that complete just reflects the work on scanning through the news items: http://hakre.wordpress.com/2012/07/30/historic-php-end-of-life-dates/ I started this to create a timeline graphic, a first draf

Re: [PHP-DEV] PHP 5.x Documentend End Of Life Dates

On 2 August 2012 16:51, Morgan L. Owens wrote: > On 2012-08-02 20:42, Peter Cowburn wrote: >> The details on things being "obsoleted" should be in the migration guides. >> > Then that would be where the links go, in a similar manner to the Changelog > links. I've added links to the migration guid

Re: [PHP-DEV] PHP 5.x Documentend End Of Life Dates

On 2012-08-02 20:42, Peter Cowburn wrote: On 2 August 2012 09:36, Morgan L. Owens wrote: Just as each release announcement dated with detailed kept on a distinct page (linked in that list), all that's needed there is a date when support ended, with (any available) information on what was obsole

Re: Re: [PHP-DEV] PHP 5.x Documentend End Of Life Dates

On 2 August 2012 09:36, Morgan L. Owens wrote: > Just as each release announcement dated with detailed kept on a distinct > page (linked in that list), all that's needed there is a date when support > ended, with (any available) information on what was obsoleted in the process > also on a distinct

Re: [PHP-DEV] PHP 5.x Documentend End Of Life Dates

Adam Harvey wrote: Thoughts? (Do we even want to auto-fill this from $OLDRELEASES, or would we rather have a manual array?) Specific notes on vulnerabilities to add to branches? Better versions of the copy in the initial blurb? A little academic now, but I was convinced that 5.1 had some more o

Re: Re: [PHP-DEV] PHP 5.x Documentend End Of Life Dates

On 2012-08-02 19:56, Peter Cowburn wrote: On 2 August 2012 07:35, Adam Harvey wrote: Thoughts? (Do we even want to auto-fill this from $OLDRELEASES, or would we rather have a manual array?) Specific notes on vulnerabilities to add to branches? Better versions of the copy in the initial blurb?

Re: [PHP-DEV] PHP 5.x Documentend End Of Life Dates

On 2 August 2012 15:56, Peter Cowburn wrote: > On 2 August 2012 07:35, Adam Harvey wrote: >> Thoughts? (Do we even want to auto-fill this from $OLDRELEASES, or >> would we rather have a manual array?) Specific notes on >> vulnerabilities to add to branches? Better versions of the copy in the >> i

Re: [PHP-DEV] PHP 5.x Documentend End Of Life Dates

On 2 August 2012 07:35, Adam Harvey wrote: > Thoughts? (Do we even want to auto-fill this from $OLDRELEASES, or > would we rather have a manual array?) Specific notes on > vulnerabilities to add to branches? Better versions of the copy in the > initial blurb? Why is this information not just disp

Re: [PHP-DEV] Implicit isset in ternary operator

So... I was thinking of proposing that we perhaps leave Arrays as is w/r/t undefined indices, while fixing up the ArrayObject gaps and making that the "smart" one (wrap/box in an AO if you want expanded/overloadable functionality). That idea was based on my belief that ArrayObject::offsetGet alrea