Re: [PHP-DEV] RFC: constructor argument promotion
Hi Sean, thanks for your answers. Am 08.08.2013 um 02:54 schrieb Sean Cannella se...@fb.com: It does in the sense the same way as the current mode enforces types on properties. That is, there's no guarantee that types will remain as initially set, only that the values passed to the constructor must be X type, ergo the post-ctor values of the props will be of type X. I can see the argument that it suggests real (permanent) typing where none exists though. [...] Makes sense. Given that, I don’t feel the shorter syntax is worth the WTF :) cu, Lars signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [PHP-DEV] php_serialize session serialize handler
Yasuo Ohgaki wrote: Or make it optional for 5.5 and 5.6, write full documentation about serializer and make new serializer default for future releases. It would work better. There would be enough time for users may have BC issue. If they do, it would be simple task to adopt because it is plain serialize(). What do you think? The one thing that PHP used to have was consistency. Applications that were designed on PHP4 worked on PHP5, and those developed on PHP5 could be made backwards compatible. This allowed sites to run and run without any major reworking. Then E_STRICT came along, and while it can be 'switched off', ignoring it creates many more problems. At what point will these fixes simply be dropped altogether, and the remaining legacy code HAS to be converted? If one was starting again today would things be done the same way? Obviously not, but this continual picking away at core functionality is a further distraction from keeping sites working? I'm currently battling with owncloud which works perfectly on Apache 2.2, but crashes without ANY error messages on Apache 2.4. I've asked for help on the Apache list and basically been told to 'piss off' as I often am here! But the people who keep pushing all these little changes 'just to make things better' need to start helping fix the breaks. phpdocs is still not producing good documentation for many of the namespace changes and other extras included in PHP5.3 let alone 5.4, and now other changes are being proposed that would require further rework on phpdocs and Reflections? The current builds of phpdocs do not actually yet produce output that matches the previous version following a complete rework of that which now requires many days of work simply to understand the new code base :( We need to help get the rest of the infrastructure working with PHP5.4 before starting work on 5.6 ... let alone 5.5 ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] VCS Account Request: requinix
On 8 August 2013 05:35, Hannes Magnusson hannes.magnus...@gmail.com wrote: \o/ I've approved your request, which means you have full karma on bugs.php.net and wiki.php.net. Good to have you on board, Damian. :)
Re: [PHP-DEV] RFC: constructor argument promotion
On 7 August 2013 20:47, Sean Cannella se...@fb.com wrote: https://wiki.php.net/rfc/constructor-promotion What do you all think? I'm not sure what problem this is really trying to solve, the boilerplate code you mention is very explicit and it is very clear to the reader what is being done. Each property documented with its type, purpose and visibility in a common place for easy reference (at the top of the class). Each property that takes a value from the constructor assigned in the constructor. Very clear. To me this seems to be adding unnecessary magic and extra rules to remember (the contrived case you mention at the bottom of the RFC for example would actually be incredibly common) at the expense of readability and code clarity.
Re: [PHP-DEV] php_serialize session serialize handler
Hi Lester, On Thu, Aug 8, 2013 at 5:26 PM, Lester Caine les...@lsces.co.uk wrote: We need to help get the rest of the infrastructure working with PHP5.4 before starting work on 5.6 ... let alone 5.5 ... Since 5.5 is just released, some fixes may be good to add. However, I agree that released version is better to keep the feature sets as it is released. I'll just commit this to master branch and document it as 5.6 feature. Any more comments? -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] RFC: constructor argument promotion
On 08.08.2013 10:34, Leigh wrote: I'm not sure what problem this is really trying to solve, the boilerplate code you mention is very explicit and it is very clear to the reader what is being done. Each property documented with its type, purpose and visibility in a common place for easy reference (at the top of the class). Each property that takes a value from the constructor assigned in the constructor. Very clear. I for one am pretty tired of writing this boilerplate in every second class I write. Using dependency injection you end up having to write a LOT of those usually, and constructors typically only contain assignments. Adding a property means: declaring the property, adding the ctor arg, adding the assignment in the ctor. You have to write the property name 4 times. With this RFC in it'd come down to writing it once, and would avoid having undeclared properties because someone forgot. I am very supportive the idea, although I see that it could be confusing to some. Maybe the syntax needs to change, but the overall change is much welcome. Cheers -- Jordi Boggiano @seldaek - http://nelm.io/jordi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php_serialize session serialize handler
Sorry I failed at reply to all. On 8 August 2013 11:38, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Leigh, On Thu, Aug 8, 2013 at 7:23 PM, Leigh lei...@gmail.com wrote: Are you keeping it as optional for 5.6 and not the default? If you're making it default don't we need to vote on BC breaks? I suppose affected users are other language users, but there are codes that outside of our control. I'm not going to remove old serializers. BC issue is matter of php.ini setting for them. If many of us feel vote is needed, I don't mind at all writing RFC. Well a change to default behaviour is a BC break. In my opinion its fine to add a new serialise handler, but I'm not sure if it should be default behaviour.
Re: [PHP-DEV] php_serialize session serialize handler
Hi Leigh, On Thu, Aug 8, 2013 at 7:53 PM, Leigh lei...@gmail.com wrote: but I'm not sure if it should be default behaviour. What's the point of having old serialzers that is bonded to register_globals? This kind of change should have done when 5.4.0 was released, IMO. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] RFC: constructor argument promotion
Am 08.08.2013 12:34 schrieb Jordi Boggiano j.boggi...@seld.be: On 08.08.2013 10:34, Leigh wrote: I'm not sure what problem this is really trying to solve, the boilerplate code you mention is very explicit and it is very clear to the reader what is being done. Each property documented with its type, purpose and visibility in a common place for easy reference (at the top of the class). Each property that takes a value from the constructor assigned in the constructor. Very clear. I for one am pretty tired of writing this boilerplate in every second class I write. Using dependency injection you end up having to write a LOT of those usually, and constructors typically only contain assignments. Adding a property means: declaring the property, adding the ctor arg, adding the assignment in the ctor. You have to write the property name 4 times. With this RFC in it'd come down to writing it once, and would avoid having undeclared properties because someone forgot. I am very supportive the idea, although I see that it could be confusing to some. Maybe the syntax needs to change, but the overall change is much welcome. The syntax itself i feel is self explaining. You read it and you know whats going on. But somehow i feel this is wrong. Declaring visibility directly in the arguments? This looks very scary to me. (Maybe only because i've never seen it before...) Other reasons against: Phpdoc generator break Code completion break If constructor is not at the beginning never see a var declaration Auto generation of set/get can be achieved with IDE..so its not much work
Re: [PHP-DEV] php_serialize session serialize handler
On 8 August 2013 12:05, Yasuo Ohgaki yohg...@ohgaki.net wrote: What's the point of having old serialzers that is bonded to register_globals? This kind of change should have done when 5.4.0 was released, IMO. Because somebodies code will depend on functionality not changing, and we shouldn't break their code without a very good reason. I can't judge the scope of the break, or how many users will be affected. I just want to say that breaks without a good reason shouldn't happen.
Re: [PHP-DEV] php_serialize session serialize handler
Leigh wrote: On 8 August 2013 12:05, Yasuo Ohgakiyohg...@ohgaki.net wrote: What's the point of having old serialzers that is bonded to register_globals? This kind of change should have done when 5.4.0 was released, IMO. Because somebodies code will depend on functionality not changing, and we shouldn't break their code without a very good reason. I can't judge the scope of the break, or how many users will be affected. I just want to say that breaks without a good reason shouldn't happen. Seconded. In hindsight I personally would have preferred to remain with clean PHP5.2 code and should have carried on with that. I've wasted many many months reworking everything for PHP5.4 and so I'm now at a stage where my real answer is probably Do what you like, I'll stick with and maintain PHP5.4 now. The problem is that ISP's like Go Daddy will still switch versions without any regard to users as they have just done with Apache 2.4 so we all end up having to live with other peoples decisions :( I still have sites where 'register_globals' is on simply because I've not had any time to rework perfectly functional systems and I can avoid anybody else changing the infrastructure! Nobody will pay for changing those sites ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [RFC] Importing namespaced functions
Hi everyone, I just wanted to bump this topic, since there's not been much feedback during the last few weeks. Comments on the patch are also welcome. RFC: https://wiki.php.net/rfc/use_function Patch: https://github.com/php/php-src/pull/388 Thanks, Igor -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I want to work against Bug 44522 - Upload limit 2G
On 6 August 2013 23:00, Michael Wallner m...@php.net wrote: Alright, I rebased the 2Gupload branch against stdint: https://github.com/m6w6/php-src/compare/2Guploads https://github.com/m6w6/php-src/compare/stdint So, is everyone fine with it so far? -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I want to work against Bug 44522 - Upload limit 2G
On 08.08.2013 14:42, Michael Wallner wrote: On 6 August 2013 23:00, Michael Wallner m...@php.net wrote: Alright, I rebased the 2Gupload branch against stdint: https://github.com/m6w6/php-src/compare/2Guploads https://github.com/m6w6/php-src/compare/stdint So, is everyone fine with it so far? I'm fine with this. Juggling around with types to get a crossplatform 64bit type was not so easy for me. -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: l...@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] I want to work against Bug 44522 - Upload limit 2G
Hi Michael 2013/8/8 Michael Wallner m...@php.net: On 6 August 2013 23:00, Michael Wallner m...@php.net wrote: Alright, I rebased the 2Gupload branch against stdint: https://github.com/m6w6/php-src/compare/2Guploads https://github.com/m6w6/php-src/compare/stdint So, is everyone fine with it so far? I think it is a long overdue that we have not have had this patch or similar committed, so I would say go a head and commit it to master. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: constructor argument promotion
Le 08/08/2013 13:11, Martin Keckeis a écrit :
Am 08.08.2013 12:34 schrieb Jordi Boggiano j.boggi...@seld.be:
On 08.08.2013 10:34, Leigh wrote:
I'm not sure what problem this is really trying to solve, the
boilerplate
code you mention is very explicit and it is very clear to the reader
what
is being done. Each property documented with its type, purpose and
visibility in a common place for easy reference (at the top of the
class).
Each property that takes a value from the constructor assigned in the
constructor. Very clear.
I for one am pretty tired of writing this boilerplate in every second
class I write. Using dependency injection you end up having to write a
LOT of those usually, and constructors typically only contain assignments.
Adding a property means: declaring the property, adding the ctor arg,
adding the assignment in the ctor. You have to write the property name 4
times. With this RFC in it'd come down to writing it once, and would
avoid having undeclared properties because someone forgot.
I am very supportive the idea, although I see that it could be confusing
to some. Maybe the syntax needs to change, but the overall change is
much welcome.
The syntax itself i feel is self explaining. You read it and you know whats
going on.
But somehow i feel this is wrong. Declaring visibility directly in the
arguments? This looks very scary to me. (Maybe only because i've never seen
it before...)
Other reasons against:
Phpdoc generator break
Code completion break
If constructor is not at the beginning never see a var declaration
Auto generation of set/get can be achieved with IDE..so its not much work
I second the feeling about the syntax, there are too many disadvantages.
However the idea is excellent.
Maybe an alternative approach could do, here is a random suggestion (a
bit more verbose):
class MyClass {
public $foo;
protected $bar;
public function __construct($this-foo, $this-bar, $baz) {
// $this-foo and $this-bar are now set
$baz-doAnything(); // $baz is a standard parameter
}
}
This would even be compatible with an interface:
interface MyInterface {
function __construct($foo, $bar, $baz);
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] handling non-fatal compile-time errors
Hi, I've just bumped into https://bugs.php.net/bug.php?id=65322 recently, and I would like you get some opinions on the issue. Personally I think that it is a really bad design to introduce pedantic(E_STRICT) errors which can break basic functionality of the engine (calling the registered autoloader), so if there is no viable solution to make the autoloader work for these kind of errors, I would like to propose removing the offending errors and make it a rule to not add compile-time non-fatal errors until the problem is resolved. ps: on a related note, somehow I got the feeling that Lester complaining that E_STRICT errors fataling/crashing the application migrated to PHP 5.4 was related to this problem, and I'm a bit sad that we didn't managed to figure this out back then. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] RFC: constructor argument promotion
On 8 August 2013 14:12, Matthieu Napoli matth...@mnapoli.fr wrote:
class MyClass {
public $foo;
protected $bar;
public function __construct($this-foo, $this-bar, $baz) {
// $this-foo and $this-bar are now set
This actually feels _way_ more intuitive to me, it feels like you are
passing the parameter directly into that property.
With that style, why even limit it to the ctor?
function mySetter(array $this-items) {}
AW: [PHP-DEV] RFC: constructor argument promotion
I agree, that looks nice. It is still readable IMO and removes the
boilerplate code in the constructor (and setters and where needed)
This proposal seems much better to me because the class members $foo and
$bar are still in the same place as usual and the compiler does not generate
magic code as before.
-Ursprüngliche Nachricht-
Von: Leigh [mailto:lei...@gmail.com]
Gesendet: Donnerstag, 8. August 2013 17:17
An: Matthieu Napoli
Cc: internals@lists.php.net
Betreff: Re: [PHP-DEV] RFC: constructor argument promotion
On 8 August 2013 14:12, Matthieu Napoli matth...@mnapoli.fr wrote:
class MyClass {
public $foo;
protected $bar;
public function __construct($this-foo, $this-bar, $baz) {
// $this-foo and $this-bar are now set
This actually feels _way_ more intuitive to me, it feels like you are
passing the parameter directly into that property.
With that style, why even limit it to the ctor?
function mySetter(array $this-items) {}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
AW: [PHP-DEV] Re: [RFC] Importing namespaced functions
Hi Igor, Personally I like your RFC. I also like the fact that it is possible to replace built-in functions where desired by declaring a corresponding use statement. I do not see aliases in your RFC but I guess it would also be possible to write things like: use function foo\bar as foo; cheers, Robert -Ursprüngliche Nachricht- Von: Igor Wiedler [mailto:i...@wiedler.ch] Gesendet: Donnerstag, 8. August 2013 14:29 An: internals@lists.php.net Betreff: [PHP-DEV] Re: [RFC] Importing namespaced functions Hi everyone, I just wanted to bump this topic, since there's not been much feedback during the last few weeks. Comments on the patch are also welcome. RFC: https://wiki.php.net/rfc/use_function Patch: https://github.com/php/php-src/pull/388 Thanks, Igor -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Importing namespaced functions
Yes, aliases are supported just as you would expect. I will add an example to the RFC. Thanks, Igor On Aug 8, 2013, at 8:17 PM, Robert Stoll rst...@tutteli.ch wrote: Hi Igor, Personally I like your RFC. I also like the fact that it is possible to replace built-in functions where desired by declaring a corresponding use statement. I do not see aliases in your RFC but I guess it would also be possible to write things like: use function foo\bar as foo; cheers, Robert -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Importing namespaced functions
On 8 August 2013 14:29, Igor Wiedler i...@wiedler.ch wrote: Hi everyone, I just wanted to bump this topic, since there's not been much feedback during the last few weeks. Comments on the patch are also welcome. RFC: https://wiki.php.net/rfc/use_function Patch: https://github.com/php/php-src/pull/388 I like it. It improves the state for non-OOP in PHP. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: constructor argument promotion
On 8 August 2013 17:16, Leigh lei...@gmail.com wrote:
On 8 August 2013 14:12, Matthieu Napoli matth...@mnapoli.fr wrote:
class MyClass {
public $foo;
protected $bar;
public function __construct($this-foo, $this-bar, $baz) {
// $this-foo and $this-bar are now set
This actually feels _way_ more intuitive to me, it feels like you are
passing the parameter directly into that property.
With that style, why even limit it to the ctor?
function mySetter(array $this-items) {}
Awww. No :-/
Sorry, I have no more words on that topic.
--
Regards,
Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I want to work against Bug 44522 - Upload limit 2G
On 8 August 2013 14:44, Kalle Sommer Nielsen ka...@php.net wrote: Hi Michael 2013/8/8 Michael Wallner m...@php.net: On 6 August 2013 23:00, Michael Wallner m...@php.net wrote: Alright, I rebased the 2Gupload branch against stdint: https://github.com/m6w6/php-src/compare/2Guploads https://github.com/m6w6/php-src/compare/stdint So, is everyone fine with it so far? I think it is a long overdue that we have not have had this patch or similar committed, so I would say go a head and commit it to master. Thought so. I'll merge tomorrow. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] zend bison check
As I have no Zend karma, is anybody kind enough to merge the bison blacklist patch? https://github.com/php/php-src/pull/402 -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 5.5.2 RC1 is tagged
On 5 August 2013 17:46, Christopher Jones christopher.jo...@oracle.com wrote: On 8/5/13 8:12 AM, Jan Ehrhardt wrote: Julien Pauli in php.internals (Fri, 2 Aug 2013 10:05:00 +0200): Please test the release carefully and report any bugs. What is the best way to report things that are so small that opening an issue would be overkill? I have got some tiny remarks: - Typo in NEWS: OPcahce should be OPcache - Remove the reference to php_zip.dll in both php.ini-*'s - Add 'case 90' in ext/gd/libgd/gd_jpeg.c to avoid unknown for jpeg lib 9 Compiled all 4 variants with VC11 flawlessly. Jan Submit pull requests with patches, then nag until someone applies them. Then nag to get karma to make changes yourself. The OPCache typo is already fixed, I believe. http://git.php.net/?p=php-src.git;a=blob;f=NEWS;h=c01b43ed7bcda9d3c846df439cf32ead01c098d6;hb=refs/heads/PHP-5.5 The gd change might qualify for a bug report, so any background can be discussed. Chris -- christopher.jo...@oracle.com http://twitter.com/ghrd Free PHP Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 5.5.2 RC1 is tagged
On 8 August 2013 21:04, Michael Wallner m...@php.net wrote: On 5 August 2013 17:46, Christopher Jones christopher.jo...@oracle.com wrote: On 8/5/13 8:12 AM, Jan Ehrhardt wrote: What is the best way to report things that are so small that opening an issue would be overkill? Submit pull requests with patches, then nag until someone applies them. Then nag to get karma to make changes yourself. ++1000 PS: sorry, the send button was too tasty (re previous post) -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: constructor argument promotion
Am 08.08.2013 15:12 schrieb Matthieu Napoli matth...@mnapoli.fr:
Le 08/08/2013 13:11, Martin Keckeis a écrit :
Am 08.08.2013 12:34 schrieb Jordi Boggiano j.boggi...@seld.be:
On 08.08.2013 10:34, Leigh wrote:
I'm not sure what problem this is really trying to solve, the
boilerplate
code you mention is very explicit and it is very clear to the reader
what
is being done. Each property documented with its type, purpose and
visibility in a common place for easy reference (at the top of the
class).
Each property that takes a value from the constructor assigned in the
constructor. Very clear.
I for one am pretty tired of writing this boilerplate in every second
class I write. Using dependency injection you end up having to write a
LOT of those usually, and constructors typically only contain
assignments.
Adding a property means: declaring the property, adding the ctor arg,
adding the assignment in the ctor. You have to write the property name 4
times. With this RFC in it'd come down to writing it once, and would
avoid having undeclared properties because someone forgot.
I am very supportive the idea, although I see that it could be confusing
to some. Maybe the syntax needs to change, but the overall change is
much welcome.
The syntax itself i feel is self explaining. You read it and you know
whats
going on.
But somehow i feel this is wrong. Declaring visibility directly in the
arguments? This looks very scary to me. (Maybe only because i've never
seen
it before...)
Other reasons against:
Phpdoc generator break
Code completion break
If constructor is not at the beginning never see a var declaration
Auto generation of set/get can be achieved with IDE..so its not much work
I second the feeling about the syntax, there are too many disadvantages.
However the idea is excellent.
Maybe an alternative approach could do, here is a random suggestion (a
bit more verbose):
class MyClass {
public $foo;
protected $bar;
public function __construct($this-foo, $this-bar, $baz) {
// $this-foo and $this-bar are now set
$baz-doAnything(); // $baz is a standard parameter
}
}
This would even be compatible with an interface:
interface MyInterface {
function __construct($foo, $bar, $baz);
}
Another thing which came into my mind:
I normall create a set/get method also to a construct parameter to
overwrite and unittest it...
So then i cant use this, because i construct i also use the set mehod to be
sure the var is assigned always the same (e.g. additional input check or
exceptions)
Re: [PHP-DEV] Re: [RFC] Importing namespaced functions
Hey Igor, I love the RFC, but how about: use bar\baz() as baz; As an alternative to use function. Still new syntax, but a little less wordy. I have nothing for use const, but use const feels more natural to me than use function does. Just an idea for pondering! Dan On Thu, Aug 8, 2013 at 2:44 PM, Michael Wallner m...@php.net wrote: On 8 August 2013 14:29, Igor Wiedler i...@wiedler.ch wrote: Hi everyone, I just wanted to bump this topic, since there's not been much feedback during the last few weeks. Comments on the patch are also welcome. RFC: https://wiki.php.net/rfc/use_function Patch: https://github.com/php/php-src/pull/388 I like it. It improves the state for non-OOP in PHP. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php_serialize session serialize handler
Hi, On Thu, Aug 8, 2013 at 9:10 PM, Lester Caine les...@lsces.co.uk wrote: Leigh wrote: I can't judge the scope of the break, or how many users will be affected. I just want to say that breaks without a good reason shouldn't happen. Seconded. In hindsight I personally would have preferred to remain with clean PHP5.2 code and should have carried on with that. I've wasted many many months reworking everything for PHP5.4 and so I'm now at a stage where my real answer is probably Do what you like, I'll stick with and maintain PHP5.4 now. The problem is that ISP's like Go Daddy will still switch versions without any regard to users as they have just done with Apache 2.4 so we all end up having to live with other peoples decisions :( I still have sites where 'register_globals' is on simply because I've not had any time to rework perfectly functional systems and I can avoid anybody else changing the infrastructure! Nobody will pay for changing those sites ... I think you are confused. How php_serialize would cause BC issues for PHP users? Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] zend bison check
On 08/08/13 20:56, Michael Wallner wrote: As I have no Zend karma, is anybody kind enough to merge the bison blacklist patch? https://github.com/php/php-src/pull/402 Maybe it should be bison_version_exclude=none so that the error message is nicer? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] zend bison check
Hi, I proposed that specify any bison as developer wants. It seems it is not merged, yet. Usage: YACC=/usr/local/bin/mybison ./configure diff --git a/Zend/acinclude.m4 b/Zend/acinclude.m4 index 454513f..1440a2a 100644 --- a/Zend/acinclude.m4 +++ b/Zend/acinclude.m4 @@ -12,7 +12,7 @@ AC_DEFUN([LIBZEND_BISON_CHECK],[ bison_version=none if test $YACC; then AC_CACHE_CHECK([for bison version], php_cv_bison_version, [ - bison_version_vars=`bison --version 2 /dev/null | grep 'GNU Bison' | cut -d ' ' -f 4 | $SED -e 's/\./ + bison_version_vars=`$YACC --version 2 /dev/null | grep 'GNU Bison' | cut -d ' ' -f 4 | $SED -e 's/\./ php_cv_bison_version=invalid if test -n $bison_version_vars; then set $bison_version_vars -- Yasuo Ohgaki yohg...@ohgaki.net On Fri, Aug 9, 2013 at 8:05 AM, Ángel González keis...@gmail.com wrote: On 08/08/13 20:56, Michael Wallner wrote: As I have no Zend karma, is anybody kind enough to merge the bison blacklist patch? https://github.com/php/php-**src/pull/402https://github.com/php/php-src/pull/402 Maybe it should be bison_version_exclude=none so that the error message is nicer? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
