[PHP-BUG] Req #61182 [NEW]: Assume Opening PHP Tag

2012-02-25 Thread tom at tomwardrop dot com
From: 
Operating system: 
PHP version:  5.4.0RC8
Package:  *Configuration Issues
Bug Type: Feature/Change Request
Bug description:Assume Opening PHP Tag

Description:

PHP is probably the only language I know which requires an opening tag (i.e
.

In the early days, when web pages were mostly static, and PHP was used to
add 
dynamic elements, it made sense to require an opening tag to drop-into PHP

execution. These days however, the opposite is more often the case. You
normally 
have a complete PHP web application, into which HTML and other static text
is 
inject, rather than injecting dynamic elements into static web pages.

What I'd like to see is a new directive added to php.ini. Call it what you
want, 
e.g. assume_open_tag or omit_open_tag.

This would require a few changes in coding practice. For example, if 
omit_open_tag is On, then the behaviour of the include() and require() 
constructs will change. They too will assume the files being required
contain 
PHP from line 1. Programmer will not longer be able to use include() and 
require() to load file contents, instead the programmer would have to use 
file_get_contents or some other alternative, though this would arguably a
good 
thing, as using require() and include() to load and output non-php could be

vulnerability, hence it's already bad practice to use include/require() to
load 
non-PHP files.

I think this change would be consistant with some of the changes made in
5.4 
which demonstrates PHP embracing modern programming idioms from other
languages. 
Ideally, I'd like this to become the default behaviour of PHP, though
obviously 
for at least the first major release, it would of course be defaulted to
Off.

Thoughts?


-- 
Edit bug report at https://bugs.php.net/bug.php?id=61182&edit=1
-- 
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61182&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61182&r=trysnapshot53
Try a snapshot (trunk):  
https://bugs.php.net/fix.php?id=61182&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61182&r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=61182&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61182&r=alreadyfixed
Need backtrace:  
https://bugs.php.net/fix.php?id=61182&r=needtrace
Need Reproduce Script:   
https://bugs.php.net/fix.php?id=61182&r=needscript
Try newer version:   
https://bugs.php.net/fix.php?id=61182&r=oldversion
Not developer issue: 
https://bugs.php.net/fix.php?id=61182&r=support
Expected behavior:   
https://bugs.php.net/fix.php?id=61182&r=notwrong
Not enough info: 
https://bugs.php.net/fix.php?id=61182&r=notenoughinfo
Submitted twice: 
https://bugs.php.net/fix.php?id=61182&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61182&r=globals
PHP 4 support discontinued:  
https://bugs.php.net/fix.php?id=61182&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61182&r=dst
IIS Stability:   
https://bugs.php.net/fix.php?id=61182&r=isapi
Install GNU Sed: 
https://bugs.php.net/fix.php?id=61182&r=gnused
Floating point limitations:  
https://bugs.php.net/fix.php?id=61182&r=float
No Zend Extensions:  
https://bugs.php.net/fix.php?id=61182&r=nozend
MySQL Configuration Error:   
https://bugs.php.net/fix.php?id=61182&r=mysqlcfg



Req #61182 [Opn]: Assume Opening PHP Tag

2012-02-25 Thread tom at tomwardrop dot com
Edit report at https://bugs.php.net/bug.php?id=61182&edit=1

 ID: 61182
 User updated by:    tom at tomwardrop dot com
 Reported by:    tom at tomwardrop dot com
 Summary:Assume Opening PHP Tag
 Status: Open
 Type:   Feature/Change Request
 Package:*Configuration Issues
 PHP Version:5.4.0RC8
 Block user comment: N
 Private report: N

 New Comment:

Are there not other directives that can break a lot of code? Remember, this 
would default to off. I don't see why as a server owner, I should have this 
option made unavailable purely because it can break other code. If you wanted 
to 
write code that worked regardless of this setting, you could do something like:



Of course, for that to work then implicit_open_tag is On, the parser would have 
to ignore the "". This would be shorthand for opening 
and 
closing a php tag, and should be placed at the top of any template file that 
has 
the requirement to work regardless of whether the opening tag is optional.

I hope this idea isn't dismissed on the grounds that it's difficult to 
implement, because I think it's workable. Having optional opening tags would no 
doubt be a step in the right direction for PHP, and I'm sure that if you didn't 
have backwards compatible to be concerned about, you'd probably make opening 
tags implicit with no option to make it otherwise. As I said earlier, the 
decision to make the opening tag explicit was desirable at the time PHP was 
conceived, but I believe it's one of those legacy decisions that needs to be re-
evaluated.


Previous Comments:

[2012-02-25 08:50:31] ras...@php.net

So this would basically be a "break all existing code" .ini switch? I don't 
think 
that is a good idea.

--------------------
[2012-02-25 08:37:03] tom at tomwardrop dot com

Description:

PHP is probably the only language I know which requires an opening tag (i.e .

In the early days, when web pages were mostly static, and PHP was used to add 
dynamic elements, it made sense to require an opening tag to drop-into PHP 
execution. These days however, the opposite is more often the case. You 
normally 
have a complete PHP web application, into which HTML and other static text is 
inject, rather than injecting dynamic elements into static web pages.

What I'd like to see is a new directive added to php.ini. Call it what you 
want, 
e.g. assume_open_tag or omit_open_tag.

This would require a few changes in coding practice. For example, if 
omit_open_tag is On, then the behaviour of the include() and require() 
constructs will change. They too will assume the files being required contain 
PHP from line 1. Programmer will not longer be able to use include() and 
require() to load file contents, instead the programmer would have to use 
file_get_contents or some other alternative, though this would arguably a good 
thing, as using require() and include() to load and output non-php could be 
vulnerability, hence it's already bad practice to use include/require() to load 
non-PHP files.

I think this change would be consistant with some of the changes made in 5.4 
which demonstrates PHP embracing modern programming idioms from other 
languages. 
Ideally, I'd like this to become the default behaviour of PHP, though obviously 
for at least the first major release, it would of course be defaulted to Off.

Thoughts?







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=61182&edit=1


Req #61182 [Opn]: Assume Opening PHP Tag

2012-02-25 Thread tom at tomwardrop dot com
Edit report at https://bugs.php.net/bug.php?id=61182&edit=1

 ID: 61182
 User updated by:    tom at tomwardrop dot com
 Reported by:    tom at tomwardrop dot com
 Summary:Assume Opening PHP Tag
 Status: Open
 Type:   Feature/Change Request
 Package:*Configuration Issues
 PHP Version:5.4.0RC8
 Block user comment: N
 Private report: N

 New Comment:

It's not just about the extra characters, but like the end ?> tag (which 
thankfully is optional), any white-space or otherwise non-printable characters 
before the opening tag can cause "headers sent" issues. You could solve that 
problem by implementing the ignore white-space rule I've already mentioned, 
where any white-space before the opening tag is ignored.

The more I think about this and talk to the others, the more it becomes 
apparent 
that what I'm actually asking for, is a distinction to made between PHP 
templates, and PHP scripts/applications. If PHP were to define these two 
distinct concepts, then you could do more than just make the opening tag 
optional. For example, you could have a template() or render() method to act as 
an include() for php templates. Unlike include() however, this render() method 
would return the output of the file, instead of sending it straight to the 
browser. This would negate the need to capture template output using the output 
buffer functions (something that I believe most frameworks end up using).

Making such a distinction would also allow web servers like Apache to treat PHP 
files differently. You may create a rule in Apache to render all .phpt files as 
PHP templates, rendering everything else as PHP script or application files. We 
may then see mod_php implement an application mode, where one can define a 
single-point of entry into their application. This could have flow-on 
performance benefits, where mod_php could cache the parsed PHP, then either 
fork 
it on each request, or instantiate a new application class. Such a feature 
would 
mean frameworks wouldn't have to stuff around with .htaccess files, and would 
mean that programmers don't need to add the following to the top of all their 
files: if (defined('SOME_CONSTANT')) exit;

While there's momentum among the PHP developers to move forward with 
modernising 
the language, I think now would be a good idea to consider some of these more 
fundamental changes. PHP's built-in template engine, ease of deployment, and 
it's dynamic, traditional OO constructs would still remain PHP's strengths.

With all this said, I'd be happy to save such changes to a major release 
intended to break legacy code, like PHP 6. I'd like to keep in mind too that 
code portability isn't relevant to most people who don't intend to release 
their 
code as open source. Typically, those people using PHP in a business context 
have control of their server. It's only shared hosting environments where 
portability becomes a potential issue. All I'm saying is don't rule out ideas 
based on the lowest common denominator.


Previous Comments:

[2012-02-25 14:12:03] phpmpan at mpan dot pl

After a bit of thinking I came to a conclusion that PHARs can, in theory, have 
such thing implemented. Some metadata may be included in PHAR to tell PHP that 
every source file in the archive assumes "" tag. Thought it's used to *enable* 
`assume_open_tag`. But, if you want to use it to disable the feature, it's even 
worse. This breaks lots of existing code. Mixing PHP with HTML is an example of 
bad design, but there are lots of such things and PHP devs can't just say "from 
today your code is not working, because we have decided to break it". Adding 
some magical sequence of characters at the begining is not a solution for this 
problem. Do you imagine administrators going through all of the files on their 
servers and adding "" to fix the broken code? Even harder to imagine in 
case of obfuscated or PHARed code.

I believe there is enough problems with server incompatibilities already. No 
need to make next one. I would be much more happy to see UTF-8 to be a standard 
feature on every host. A requirement to write "" at the 
begining of the file to not write "" thing is optional. The problem is that virtually any 
code has to use it to be portable. This means it's not really optional.


[2012-02-25 09:24:21] tom at tomwardrop dot com

Are there not other directives that can break a lot of code? Remember, this 
would default to off. I don't see why as a server owner, I should have this 
option made unavailable purely because it can break other code. If you wanted 
to 
write code that worked rega

Req #61182 [Opn]: Assume Opening PHP Tag

2012-02-25 Thread tom at tomwardrop dot com
Edit report at https://bugs.php.net/bug.php?id=61182&edit=1

 ID: 61182
 User updated by:    tom at tomwardrop dot com
 Reported by:    tom at tomwardrop dot com
 Summary:Assume Opening PHP Tag
 Status: Open
 Type:   Feature/Change Request
 Package:*Configuration Issues
 PHP Version:5.4.0RC8
 Block user comment: N
 Private report: N

 New Comment:

I do agree with you, hence my last comment. Adding optional open tags alone 
would be more hassle than it's worth, you're right. However, if PHP was to 
provide more than just optional open tags, like some of the application-
orientated features I've mentioned, then the hassle would probably be worth it. 
Of course, this goes beyond the scope of this feature request, but it would 
make 
for an interesting discussion none-the-less. PHP is overdue to receive some 
kind 
of application persistance so code isn't re-parsed and re-initialized after 
every request.

I'm happy for this ticket to be closed, though I would love to see more thought 
put into evolving PHP beyond its current template-orientated form, which lately 
seems to work against developers more than it helps them.


Previous Comments:

[2012-02-26 01:47:05] phpmpan at mpan dot pl

Note: I'm NOT against the idea itself. I'm just thinking that in the current 
form it can do more harm than good.

What you're asking for is redefining the whole PHP world. Let's imagine that 
PHP6 includes your idea and it's *not* optional. What happens?
1. Many of PHP books become obsolete
   We all know mixing code and output is bad, but the books
   take this approach because it's simpler. It allows authors
   to show the basic ideas of PHP without requiring the reader
   to download/install third party template engine.
   But if .php files are no longer templates, books need
   to be rewritten. Lots of money for authors, but I think
   it's not dev's goal.
2. Lots of currently used code becomes obsolete
   If one needs to write code for a server that has
   this feature enabled, any template-like code should
   be avoided. This means we can use only "safe" libraries.
   Which are "safe"? Only those for which the author states
   they're compatible with `assume_open_tags`.
   In other words: less code for us to use. Many things needs
   to be rewritten. This is bad.
3. Admins will simply refuse to enable the feature
   I love the idea of removing magic_quotes. At the same time
   I believe many admins will hesitate to upgrade to PHP6,
   because they have irrational belief that the magic_quotes
   feature was protecting them.
   Now imagine what will they do with `assume_open_tags`.
   Will they enable it? Will they risk breaking already
   deployed applications? I don't think so. If they're afraid
   to leave their servers without magic_quote "protection",
   they'll be even more scared of the fact that they can beak
   something seriously by enabling `assume_open_tags`.
   Setting `assume_open_tags` on per-directory basis (for example
   with .htaccess in Apache) doesn't solve the problem, because
   PHP libraries may be shared between multiple applications.
I believe that books should be rewritten, real template engines should be used, 
we should update our code et cetera. But real life is real life. Encountering 
pieces of software that were not upgraded for 20-30 years is not an uncommon 
thing ("20-30yrs" does not apply to PHP, but I know apps that were not updated 
since PHP4). `magic_quotes` are deprecated for years and many people seen 
they're bad even earlier. There was enough time to update applications that 
depends on them. And even if some code is not fixed, removing magic_quotes 
doesn't make it stop working. The case of `assume_open_tags` is different. If 
it's optional, it needs to become a standard to be accepted. And this should be 
done quickly. I can't imagine building separate versions of libraries for 
server with this feature enabled and without it. Authors will simply keep using 
versions with " tag (which 
thankfully is optional), any white-space or otherwise non-printable characters 
before the opening tag can cause "headers sent" issues. You could solve that 
problem by implementing the ignore white-space rule I've already mentioned, 
where any white-space before the opening tag is ignored.

The more I think about this and talk to the others, the more it becomes 
apparent 
that what I'm actually asking for, is a distinction to made between PHP 
templates, and PHP scripts/applications. If PHP were to define these two 
distinct concepts, then you could do more than just make the opening tag 
optional. For example, you could have a template() or render() method to act 

Req #52504 [Com]: Support relative namespaces

2012-02-26 Thread tom at tomwardrop dot com
Edit report at https://bugs.php.net/bug.php?id=52504&edit=1

 ID: 52504
 Comment by:     tom at tomwardrop dot com
 Reported by:robert dot de dot wilde at online dot nl
 Summary:Support relative namespaces
 Status: Open
 Type:   Feature/Change Request
 Package:Class/Object related
 Operating System:   Any
 PHP Version:5.3.3
 Block user comment: N
 Private report: N

 New Comment:

I was just about to post the exact same feature suggestion. I'm using PHP 5.4 
RC8 
after 2 years of programming Ruby (I have a project that better lends itself to 
PHP template-orientated nature), and this was one of the first things I tried 
to 
do, reference a resource one level up in the namespace hierarchy. Luckily, my 
namespace isn't too deep, but I can imagine some of the larger frameworks which 
have 3-6+ level deep namespaces could really benefit from this.

I'm surprised none of the dev's have commented on this.


Previous Comments:

[2010-08-18 15:44:12] robert dot de dot wilde at online dot nl

Any developer can have a look?


[2010-07-31 10:54:14] giorgio dot liscio at email dot it

very nice, i really like it

it would be nice too having * on import

works only if __autoload or spl_autoload_register is used, otherwise triggers 
an error

use MyNS\Test\*;   // imports all classes in the "Test" namespace
use MyNS\Test\**;  // imports all the namespace hierarchy (including 
subpackages) from namespace Test

__autoload($className, $importAll = FALSE, $importDeep = FALSE)
{
  // handle * as a full dir import
  // ** imports subdirs too
}

in my framework i need to put

use \FW\String;
use \FW\Int;
use \FW\Float;
use \FW\Vector;
use \FW\Dictionary;
use \FW\Types;

etc in every file...


[2010-07-31 09:58:03] robert dot de dot wilde at online dot nl

Description:

It would be nice to have relative namespace support to keep code clean and 
flexible.

When inside of a namespace, it would be nice to have some directory-path-like 
option like '..'.

Test script:
---
namespace MyNs\Some\Path\Going\A\Long\Way
{
  class GoClass extends ..\..\Short\Way\GoClass  // <<
  {}
}







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=52504&edit=1


#50261 [NEW]: Crash When Calling Parent Constructor with call_user_func()

2009-11-22 Thread tom at tomwardrop dot com
From: tom at tomwardrop dot com
Operating system: Windows 7 x64
PHP version:  5.3.1
PHP Bug Type: Reproducible crash
Bug description:  Crash When Calling Parent Constructor with call_user_func()

Description:

If class B, extends Class A, and class B calls Class A's constructor in
its own contructor by using call_user_func("parent", "__construct"), and if
class A's constructor is defined as the class name rather than
"__construct", then PHP seems to crash (which results in Apache 2
crashing). Problem still exists with all extensions disabled.

Reproduce code:
---


Expected result:

The above code should echo out the string 'Output string!'. This code
works correctly when "call_user_func" or "call_user_func_array" are not
used.

Actual result:
--
call_user_func() and call_user_func_array(), cause PHP and as a result,
Apache 2 to crash. When running PHP DBG debugger, the crash happens on the
execution of call_user_func() line. The Windows event log notes that
httpd.exe (apache) had crashed, blaming php5ts.dll for the fault.


-- 
Edit bug report at http://bugs.php.net/?id=50261&edit=1
-- 
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50261&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50261&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50261&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50261&r=fixed
Fixed in SVN and need be documented: 
http://bugs.php.net/fix.php?id=50261&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50261&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=50261&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=50261&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=50261&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=50261&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=50261&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=50261&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=50261&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50261&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=50261&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50261&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=50261&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=50261&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=50261&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=50261&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=50261&r=mysqlcfg



#50261 [Opn]: Crash When Calling Parent Constructor with call_user_func()

2009-11-22 Thread tom at tomwardrop dot com
 ID:   50261
 User updated by:  tom at tomwardrop dot com
 Reported By:  tom at tomwardrop dot com
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: Windows 7 x64
 PHP Version:  5.3.1
 New Comment:

To clarify, replacing...

call_user_func(array('parent', '__construct'));

...with...

parent::__construct();

...works as expected, hence it's definitely a problem with the
"call_user_func" and "call_user_func_array" functions.


Previous Comments:
----------------

[2009-11-22 10:05:54] tom at tomwardrop dot com

Description:

If class B, extends Class A, and class B calls Class A's constructor in
its own contructor by using call_user_func("parent", "__construct"), and
if class A's constructor is defined as the class name rather than
"__construct", then PHP seems to crash (which results in Apache 2
crashing). Problem still exists with all extensions disabled.

Reproduce code:
---


Expected result:

The above code should echo out the string 'Output string!'. This code
works correctly when "call_user_func" or "call_user_func_array" are not
used.

Actual result:
--
call_user_func() and call_user_func_array(), cause PHP and as a result,
Apache 2 to crash. When running PHP DBG debugger, the crash happens on
the execution of call_user_func() line. The Windows event log notes that
httpd.exe (apache) had crashed, blaming php5ts.dll for the fault.






-- 
Edit this bug report at http://bugs.php.net/?id=50261&edit=1



Req #6418 [Com]: Multiple class extends ordering error

2010-06-02 Thread tom at tomwardrop dot com
Edit report at http://bugs.php.net/bug.php?id=6418&edit=1

 ID:   6418
 Comment by:       tom at tomwardrop dot com
 Reported by:  nathan at cjhunter dot com
 Summary:  Multiple class extends ordering error
 Status:   Wont fix
 Type: Feature/Change Request
 Package:  Feature/Change Request
 Operating System: Linux 2.0.36
 PHP Version:  4.0.1pl2

 New Comment:

I don't know the internals of PHP, but maybe someone who does can
respond to this. I agree with the comment by bj...@php.net...



"You need to declare the class before you use it.

The other way around doesn't make sense and will not ever 

be supported."



However, since when was declaring a class considered to be "using" a
class? If possible, I propose that PHP check for the availability of
extended classes and interfaces at the time an instance is created, or
when the first static call is made, rather than when the class is
declared. This is no doubt the most logical approach, but I have no idea
whether this is technically possible to implement.



We can call this feature, just-in-time class checking :-)



I look forward to hearing a response from someone who knows the part of
the PHP core that handles this.


Previous Comments:

[2007-01-07 11:26:07] bj...@php.net

You need to declare the class before you use it.

The other way around doesn't make sense and will not ever 

be supported.



With the "class per file" approach you can use autoload() 

or spl_autoload()


[2006-07-15 10:20:15] info at triin dot net

I had some quite hard time figuring out what is wrong with my code -
this defenetly is a bug, not a feature request.



I had a lot of PHP files (class in each file) and at the beginning of
each one there were the require_once statements to include all the other
classes that were used by that class. And suddenly there was a weird
collision...


[2002-09-09 09:04:35] scallop at iki dot fi

Yes, this is a feature that is definately needed in PHP.



I am currently working on a project which has very complex class
hierarchy (dozens of classes extending each other). Due to complex class
hierarchy and the huge amount of code, I am developing classes so that
each class is in it's own file. And to make it all simple, I use a small
script to combine all this classes into one huge file.



It is always possible to create a system that checks class dependencies
and creates a combined classfile with classes in proper order.



However, I think this is a feature that _should_ be provided by php.



(tested on versions 4.2.3, 4.3.0 - still not implemented)



I hope I explained my self clear enough.



See my report (marked as duplicate):

http://bugs.php.net/bug.php?id=19312


[2000-08-31 08:48:21] s...@php.net

Yes, you cannot do this in PHP. In fact, you even shouldn't try doing
this - why would you need to define class without knowing what it
extends? I move it to feature request in the meantime, in case something
will explain why this could be useful.


[2000-08-29 12:20:10] nathan at cjhunter dot com

Multiple class extends creates ordering error



The below..





gives an error 'Fatal error: Class c: Cannot inherit from undefined
class b in test.html on line 4',

but..







works fine.



I imagine this could be fixed by first ordering the classes by their
given dependencies and then process them one by one.





-- 
Edit this bug report at http://bugs.php.net/bug.php?id=6418&edit=1


#50261 [Csd]: Crash When Calling Parent Constructor with call_user_func()

2009-11-30 Thread tom at tomwardrop dot com
 ID:   50261
 User updated by:  tom at tomwardrop dot com
 Reported By:  tom at tomwardrop dot com
 Status:   Closed
 Bug Type: Reproducible crash
 Operating System: *
 PHP Version:  5.3, 6
 Assigned To:  dmitry
 New Comment:

Awesome turn around time. Well done guys, and thanks.


Previous Comments:


[2009-11-30 11:40:07] dmi...@php.net

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.





[2009-11-30 11:39:54] s...@php.net

Automatic comment from SVN on behalf of dmitry
Revision: http://svn.php.net/viewvc/?view=revision&revision=291488
Log: Fixed bug #50261 (Crash When Calling Parent Constructor with
call_user_func())



[2009-11-24 09:22:13] tony2...@php.net

Dmitry, could you take a look at it?



[2009-11-23 23:07:07] s...@php.net

Automatic comment from SVN on behalf of felipe
Revision: http://svn.php.net/viewvc/?view=revision&revision=291248
Log: - Added test for bug #50261



[2009-11-22 18:37:37] j...@php.net

In PHP_5_2 you get this error and no crash:
Warning: call_user_func(parent::__construct): First argument is
expected to be a valid callback..





The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/50261

-- 
Edit this bug report at http://bugs.php.net/?id=50261&edit=1