#34592 [NEW]: RNF: Configurable constructor lookup behavior
From: david at nap dot edu
Operating system: Redhat Linux / Fedora Core 3
PHP version: 5.0.5
PHP Bug Type: Feature/Change Request
Bug description: RNF: Configurable constructor lookup behavior
Description:
I'd like a configuration option that would disable backward-compatible
lookups of class constructor names (ie. methods named the same as the
class).
I'm attempting to implement a Hibernate-like persistence layer for php
objects. To facilitate this, several things happen at object creation
time, currently using the 'magic method' __construct in a persistent
superclass. However, I'd prefer to allow users to implement constructor
methods named as the class; in this scenario my __construct() method would
run and then use reflection to invoke the user constructor. However, this
is not possible as the presence of the class-named method currently
prevents __construct from being called.
So, it would be useful to me to be able to switch off this behavior. If
there is interest in this but no time I'd be happy to provide a patch.
Reproduce code:
---
class A {
function __construct() {
echo A ctor\n;
}
}
class B extends A {
function B() {
echo B ctor\n;
}
}
$foo = new B();
Expected result:
I'd like a php.ini option that would cause the result to be
A ctor
or even
A ctor
B ctor
if that is somehow more desirable.
Actual result:
--
Currently, the result is
B ctor
--
Edit bug report at http://bugs.php.net/?id=34592edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34592r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=34592r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=34592r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34592r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34592r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=34592r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=34592r=needscript
Try newer version: http://bugs.php.net/fix.php?id=34592r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34592r=support
Expected behavior: http://bugs.php.net/fix.php?id=34592r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=34592r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=34592r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34592r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34592r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34592r=dst
IIS Stability: http://bugs.php.net/fix.php?id=34592r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34592r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=34592r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=34592r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=34592r=mysqlcfg
#34592 [Fbk-Opn]: RNF: Configurable constructor lookup behavior
ID: 34592
User updated by: david at nap dot edu
Reported By: david at nap dot edu
-Status: Feedback
+Status: Open
Bug Type: Feature/Change Request
Operating System: Redhat Linux / Fedora Core 3
PHP Version: 5.0.5
New Comment:
Why not to override __construct() instead?
I could specify that users of my system must write constructors that
override __construct, however this has the disadvantage that they must
remember to make the call to the superclass __construct before doing
anything else (for example, assignments to class fields from a
constructor is common, and these need to be caught and mark object as
dirty). I could also do something like specify that constructors in
domain objects have an underscore prepended to the name, such as
function _MyClass() { ... }. In this case if the underscore is
forgotten, errors will ensue much later due to __construct not being
called.
Both of these seem less appealing than having users just write a ctor
in the way they are used to (named as class), and having it work.
In general, I feel there should be a way to hook object creation for
non-end-user purposes (tracing, profiling, etc, as well) that is not
disabled by the presence of a constructor written by the user who is
not aware of the workings of the (persistence, tracing, profiling, etc)
mechanism.
Previous Comments:
[2005-09-21 23:53:08] [EMAIL PROTECTED]
However, I'd prefer to allow users to implement
constructor methods named as the class;
Why not to override __construct() instead?
[2005-09-21 23:46:30] david at nap dot edu
Description:
I'd like a configuration option that would disable backward-compatible
lookups of class constructor names (ie. methods named the same as the
class).
I'm attempting to implement a Hibernate-like persistence layer for php
objects. To facilitate this, several things happen at object creation
time, currently using the 'magic method' __construct in a persistent
superclass. However, I'd prefer to allow users to implement
constructor methods named as the class; in this scenario my
__construct() method would run and then use reflection to invoke the
user constructor. However, this is not possible as the presence of the
class-named method currently prevents __construct from being called.
So, it would be useful to me to be able to switch off this behavior.
If there is interest in this but no time I'd be happy to provide a
patch.
Reproduce code:
---
class A {
function __construct() {
echo A ctor\n;
}
}
class B extends A {
function B() {
echo B ctor\n;
}
}
$foo = new B();
Expected result:
I'd like a php.ini option that would cause the result to be
A ctor
or even
A ctor
B ctor
if that is somehow more desirable.
Actual result:
--
Currently, the result is
B ctor
--
Edit this bug report at http://bugs.php.net/?id=34592edit=1
