So, I ran across bug #54631
A fatal error is thrown if you try to call parent::__construct() from a
subclass
of SplObjectStorage.
I was going to close it as "expected behavior" since that is pretty normal
if the parent class doesn't implement __construct().
Also, the docs don't list it as having a __construct() method.
But then look at SplDoublyLinkedList (and a bunch of others). They are
documented
as having a __construct() method, yet it triggers a fatal error when you try
to call
"parent::__construct()" from a subclass' constructor .
So it seems to me that there are two possible solutions:
- Update the docs to remove ::__construct() for classes that don't have one.
- Make sure __construct() is implemented in all SPL classes * and update the
docs.
- Even if it is empty.
What's everyone thinking?
I'd be more than happy to add the constructors to the code where needed, I
just
want to make sure that it is the right move first.
- Andrew
Hi!
A fatal error is thrown if you try to call parent::__construct() from a
subclass
of SplObjectStorage.
I'm thinking maybe it'll be useful to make parent::__construct silently
succeed if parent class exists but has no ctor.
The reason for that that for many classes you have to call parent ctor
for normal functionality, on the other hand some of them may not have it
clearly documented if ctor method exists or not. Also, even if ctor
method doesn't exist in fact there's always default empty one (since you
can create object without explicitly writing a ctor).
So, if we allow parent ctor always succeed it will make the code more
robust.
What do you think?
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi,
I|d actuallz suggest a different option:
If a parent constructor is called but doesn't exist the engine should
ignore this. The same goes for destructors.
This solution would also work for userland classes.
johannes
So, I ran across bug #54631
A fatal error is thrown if you try to call parent::__construct() from a
subclass
of SplObjectStorage.I was going to close it as "expected behavior" since that is pretty normal
if the parent class doesn't implement __construct().
Also, the docs don't list it as having a __construct() method.But then look at SplDoublyLinkedList (and a bunch of others). They are
documented
as having a __construct() method, yet it triggers a fatal error when you try
to call
"parent::__construct()" from a subclass' constructor .So it seems to me that there are two possible solutions:
- Update the docs to remove ::__construct() for classes that don't have one.
- Make sure __construct() is implemented in all SPL classes * and update the
docs.
- Even if it is empty.
What's everyone thinking?
I'd be more than happy to add the constructors to the code where needed, I
just
want to make sure that it is the right move first.
- Andrew
I like that idea and I like that it works for userland classes as well.
+1
Do you think it should throw a warning, notice, or -- as you both suggested
-- just silently succeed?
2011/5/16 Johannes Schlüter johannes@schlueters.de
Hi,
I|d actuallz suggest a different option:
If a parent constructor is called but doesn't exist the engine should
ignore this. The same goes for destructors.This solution would also work for userland classes.
johannes
So, I ran across bug #54631
A fatal error is thrown if you try to call parent::__construct() from a
subclass
of SplObjectStorage.I was going to close it as "expected behavior" since that is pretty
normal
if the parent class doesn't implement __construct().
Also, the docs don't list it as having a __construct() method.But then look at SplDoublyLinkedList (and a bunch of others). They are
documented
as having a __construct() method, yet it triggers a fatal error when you
try
to call
"parent::__construct()" from a subclass' constructor .So it seems to me that there are two possible solutions:
- Update the docs to remove ::__construct() for classes that don't have
one.- Make sure __construct() is implemented in all SPL classes * and update
the
docs.
- Even if it is empty.
What's everyone thinking?
I'd be more than happy to add the constructors to the code where needed,
I
just
want to make sure that it is the right move first.
- Andrew
Personally, I really don't care for something like this. Would it be
caught by a __call declaration if one existed (since it is a call to
an undefined method)? Would you expect it to?
I'd rather see calls to non-existent methods generate a catachable
fatal error (rather than a hard fatal error that's currently thrown).
That way we can use an error exception to "catch" the fatal and
recover from it if necessary.
But silently ignoring a called function, something just doesn't sit
right about that...
I like that idea and I like that it works for userland classes as well.
+1
Do you think it should throw a warning, notice, or -- as you both suggested
-- just silently succeed?2011/5/16 Johannes Schlüter johannes@schlueters.de
Hi,
I|d actuallz suggest a different option:
If a parent constructor is called but doesn't exist the engine should
ignore this. The same goes for destructors.This solution would also work for userland classes.
johannes
So, I ran across bug #54631
A fatal error is thrown if you try to call parent::__construct() from a
subclass
of SplObjectStorage.I was going to close it as "expected behavior" since that is pretty
normal
if the parent class doesn't implement __construct().
Also, the docs don't list it as having a __construct() method.But then look at SplDoublyLinkedList (and a bunch of others). They are
documented
as having a __construct() method, yet it triggers a fatal error when you
try
to call
"parent::__construct()" from a subclass' constructor .So it seems to me that there are two possible solutions:
- Update the docs to remove ::__construct() for classes that don't have
one.- Make sure __construct() is implemented in all SPL classes * and update
the
docs.
- Even if it is empty.
What's everyone thinking?
I'd be more than happy to add the constructors to the code where needed,
I
just
want to make sure that it is the right move first.
- Andrew
To play devil's advocate a bit:
It's a special case. If it was really an undefined method then this is
suddenly ambiguous:
$foo = new Foo();
If __construct() is undefined, what is being called in that case? By the
same logic, that should
throw an error as well.
On the other hand, if __construct is presumed to be implicitly defined then
I think it makes
logical sense for parent::__construct() to always succeed.
Side note:
If __construct is implicit then __destruct should also be.
On Mon, May 16, 2011 at 3:10 PM, Anthony Ferrara ircmaxell@gmail.comwrote:
Personally, I really don't care for something like this. Would it be
caught by a __call declaration if one existed (since it is a call to
an undefined method)? Would you expect it to?I'd rather see calls to non-existent methods generate a catachable
fatal error (rather than a hard fatal error that's currently thrown).
That way we can use an error exception to "catch" the fatal and
recover from it if necessary.But silently ignoring a called function, something just doesn't sit
right about that...On Mon, May 16, 2011 at 2:44 PM, Andrew Curioso andrewcurioso@gmail.com
wrote:I like that idea and I like that it works for userland classes as well.
+1
Do you think it should throw a warning, notice, or -- as you both
suggested
-- just silently succeed?2011/5/16 Johannes Schlüter johannes@schlueters.de
Hi,
I|d actuallz suggest a different option:
If a parent constructor is called but doesn't exist the engine should
ignore this. The same goes for destructors.This solution would also work for userland classes.
johannes
So, I ran across bug #54631
A fatal error is thrown if you try to call parent::__construct() from
a
subclass
of SplObjectStorage.I was going to close it as "expected behavior" since that is pretty
normal
if the parent class doesn't implement __construct().
Also, the docs don't list it as having a __construct() method.But then look at SplDoublyLinkedList (and a bunch of others). They are
documented
as having a __construct() method, yet it triggers a fatal error when
you
try
to call
"parent::__construct()" from a subclass' constructor .So it seems to me that there are two possible solutions:
- Update the docs to remove ::__construct() for classes that don't
have
one.- Make sure __construct() is implemented in all SPL classes * and
update
the
docs.
- Even if it is empty.
What's everyone thinking?
I'd be more than happy to add the constructors to the code where
needed,
I
just
want to make sure that it is the right move first.
- Andrew
--
--
Andrew Curioso
Well, if we follow that logic (which does make sense), then shouldn't
all magic methods be implicit? So parent::__sleep/__call/__get/etc
would silently do the default if not defined?
To play devil's advocate a bit:
It's a special case. If it was really an undefined method then this is
suddenly ambiguous:
$foo = new Foo();If __construct() is undefined, what is being called in that case? By the
same logic, that should
throw an error as well.On the other hand, if __construct is presumed to be implicitly defined then
I think it makes
logical sense for parent::__construct() to always succeed.Side note:
If __construct is implicit then __destruct should also be.On Mon, May 16, 2011 at 3:10 PM, Anthony Ferrara ircmaxell@gmail.com
wrote:Personally, I really don't care for something like this. Would it be
caught by a __call declaration if one existed (since it is a call to
an undefined method)? Would you expect it to?I'd rather see calls to non-existent methods generate a catachable
fatal error (rather than a hard fatal error that's currently thrown).
That way we can use an error exception to "catch" the fatal and
recover from it if necessary.But silently ignoring a called function, something just doesn't sit
right about that...On Mon, May 16, 2011 at 2:44 PM, Andrew Curioso andrewcurioso@gmail.com
wrote:I like that idea and I like that it works for userland classes as well.
+1
Do you think it should throw a warning, notice, or -- as you both
suggested
-- just silently succeed?2011/5/16 Johannes Schlüter johannes@schlueters.de
Hi,
I|d actuallz suggest a different option:
If a parent constructor is called but doesn't exist the engine should
ignore this. The same goes for destructors.This solution would also work for userland classes.
johannes
So, I ran across bug #54631
A fatal error is thrown if you try to call parent::__construct() from
a
subclass
of SplObjectStorage.I was going to close it as "expected behavior" since that is pretty
normal
if the parent class doesn't implement __construct().
Also, the docs don't list it as having a __construct() method.But then look at SplDoublyLinkedList (and a bunch of others). They
are
documented
as having a __construct() method, yet it triggers a fatal error when
you
try
to call
"parent::__construct()" from a subclass' constructor .So it seems to me that there are two possible solutions:
- Update the docs to remove ::__construct() for classes that don't
have
one.- Make sure __construct() is implemented in all SPL classes * and
update
the
docs.
- Even if it is empty.
What's everyone thinking?
I'd be more than happy to add the constructors to the code where
needed,
I
just
want to make sure that it is the right move first.
- Andrew
--
--
Andrew Curioso
That is a whole other can of worms. Whereas __construct() and __destruct()
can do nothing and are probably pretty trivial to get working, some other
methods aren't so clear cut.
Example: __sleep() would have to return an array of member variables so
that it does what is expected when called by the user. Like this...
...
public function __sleep()
{
return array_merge( parent::__sleep(), array( "foo", "bar" ) );
}
...
My only point being. I like the idea in principal but implementing it for
all magic
methods could become a somewhat major undertaking.
On Mon, May 16, 2011 at 3:28 PM, Anthony Ferrara ircmaxell@gmail.comwrote:
Well, if we follow that logic (which does make sense), then shouldn't
all magic methods be implicit? So parent::__sleep/__call/__get/etc
would silently do the default if not defined?On Mon, May 16, 2011 at 3:18 PM, Andrew Curioso andrewcurioso@gmail.com
wrote:To play devil's advocate a bit:
It's a special case. If it was really an undefined method then this is
suddenly ambiguous:
$foo = new Foo();If __construct() is undefined, what is being called in that case? By the
same logic, that should
throw an error as well.On the other hand, if __construct is presumed to be implicitly defined
then
I think it makes
logical sense for parent::__construct() to always succeed.Side note:
If __construct is implicit then __destruct should also be.On Mon, May 16, 2011 at 3:10 PM, Anthony Ferrara ircmaxell@gmail.com
wrote:Personally, I really don't care for something like this. Would it be
caught by a __call declaration if one existed (since it is a call to
an undefined method)? Would you expect it to?I'd rather see calls to non-existent methods generate a catachable
fatal error (rather than a hard fatal error that's currently thrown).
That way we can use an error exception to "catch" the fatal and
recover from it if necessary.But silently ignoring a called function, something just doesn't sit
right about that...On Mon, May 16, 2011 at 2:44 PM, Andrew Curioso <
andrewcurioso@gmail.com>
wrote:I like that idea and I like that it works for userland classes as
well.+1
Do you think it should throw a warning, notice, or -- as you both
suggested
-- just silently succeed?2011/5/16 Johannes Schlüter johannes@schlueters.de
Hi,
I|d actuallz suggest a different option:
If a parent constructor is called but doesn't exist the engine should
ignore this. The same goes for destructors.This solution would also work for userland classes.
johannes
So, I ran across bug #54631
A fatal error is thrown if you try to call parent::__construct()
from
a
subclass
of SplObjectStorage.I was going to close it as "expected behavior" since that is pretty
normal
if the parent class doesn't implement __construct().
Also, the docs don't list it as having a __construct() method.But then look at SplDoublyLinkedList (and a bunch of others). They
are
documented
as having a __construct() method, yet it triggers a fatal error
when
you
try
to call
"parent::__construct()" from a subclass' constructor .So it seems to me that there are two possible solutions:
- Update the docs to remove ::__construct() for classes that don't
have
one.- Make sure __construct() is implemented in all SPL classes * and
update
the
docs.
- Even if it is empty.
What's everyone thinking?
I'd be more than happy to add the constructors to the code where
needed,
I
just
want to make sure that it is the right move first.
- Andrew
--
--
Andrew Curioso
--
Andrew Curioso
Hi!
Well, if we follow that logic (which does make sense), then shouldn't
all magic methods be implicit? So parent::__sleep/__call/__get/etc
would silently do the default if not defined?
In most cases, you are required to call parent ctor, but there's no such
requirement for other methods. Ctors are special in a way that in 99.9%
of cases you do call parent ctor. I can't really think of any case where
you don't want to do this. Ctors are special (well, along with dtors,
but those aren't used as much).
In fact, Java, for example, always inserts parent ctor call if you don't
have one and defines empty ctor so it always works. Of course, we don't
have to follow them but this shows this pattern is known.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Well, that wasn't where I was expecting that thread to go, but to wrap it up
what do you think...
Is it too late to put this on the 5.4 roadmap for consideration?
I'm assuming just the implicit ctor and dtor. Not all magic methods (not
now, at least).
With your OK, Stas, I'd like to write up an RFC and put it on the Wiki.
- Andrew
Hi,
Well, that wasn't where I was expecting that thread to go, but to wrap it up
what do you think...
Is it too late to put this on the 5.4 roadmap for consideration?I'm assuming just the implicit ctor and dtor. Not all magic methods (not
now, at least).With your OK, Stas, I'd like to write up an RFC and put it on the Wiki.
- Andrew
The main problem with internal classes and ctors is that constructor
code can be placed at object init instead of in the actual ctor method.
It is actually safer to place it at object init, because then that code
is always executed and thus the internal object is not in a half
initialized state if the user overwrites the constructor and doesn't
call the parent.
I'd rather have ctors/dtors explicitely defined in SPL. If they are
documented to exist, they should be explicitely defined. We can define
such NOOP methods globally, so that it is easy for internal classes to add
them.
As far as implicitly ignore of the constructor, I believe we have enough
magic regarding ctors/dtors in the engine as it is.
Best,
I had given up on someone actually going with one of my original ideas for
fixing the bug!
That is where I was leaning but I would take it a step further and add
constructors to all SPL classes even if the docs don't currently list one.
In regards to the implicit ctor and dtor. I don't thing it is actually any
more or less magic than what we have now.
Ask a Java programmer, they will likely say that having the implicit ctor
and dtor just makes sense and not having one is strange.
Although, in Java, all classes descend from Object so it is not quite the
same.
Side not: of course, an RFC does not mean that it will end up in a release.
It would still need to be voted on.
The main problem with internal classes and ctors is that constructor
code can be placed at object init instead of in the actual ctor method.
It is actually safer to place it at object init, because then that code
is always executed and thus the internal object is not in a half
initialized state if the user overwrites the constructor and doesn't
call the parent.I'd rather have ctors/dtors explicitely defined in SPL. If they are
documented to exist, they should be explicitely defined. We can define
such NOOP methods globally, so that it is easy for internal classes to add
them.As far as implicitly ignore of the constructor, I believe we have enough
magic regarding ctors/dtors in the engine as it is.Best,
Hi,
Why not make all objects (maybe implicitly) extend a single root object, containing just skeleton ctor/dtor and implemented in the engine ?
I don't know if it is actually possible in PHP, but that works for several other languages (java, objC - in that case, the root object is explicit-, C# AFAR)
This would also bypass the error-level debate (no error would be thrown)
--
Regards,
Benjamin Dubois
Le 16 mai 2011 à 23:25, Etienne Kneuss a écrit :
Hi,
Well, that wasn't where I was expecting that thread to go, but to wrap it up
what do you think...
Is it too late to put this on the 5.4 roadmap for consideration?I'm assuming just the implicit ctor and dtor. Not all magic methods (not
now, at least).With your OK, Stas, I'd like to write up an RFC and put it on the Wiki.
- Andrew
The main problem with internal classes and ctors is that constructor
code can be placed at object init instead of in the actual ctor method.
It is actually safer to place it at object init, because then that code
is always executed and thus the internal object is not in a half
initialized state if the user overwrites the constructor and doesn't
call the parent.I'd rather have ctors/dtors explicitely defined in SPL. If they are
documented to exist, they should be explicitely defined. We can define
such NOOP methods globally, so that it is easy for internal classes to add
them.As far as implicitly ignore of the constructor, I believe we have enough
magic regarding ctors/dtors in the engine as it is.Best,
Am 17.05.2011 um 02:22 schrieb Benjamin Dubois benjamin.dubois@gmail.com:
Hi,
Why not make all objects (maybe implicitly) extend a single root object, containing just skeleton ctor/dtor and implemented in the engine ?
I don't know if it is actually possible in PHP, but that works for several other languages (java, objC - in that case, the root object is explicit-, C# AFAR)
This would also bypass the error-level debate (no error would be thrown)
+1
On Tue, May 17, 2011 at 4:22 AM, Benjamin Dubois
benjamin.dubois@gmail.com wrote:
Why not make all objects (maybe implicitly) extend a single root object, containing just skeleton ctor/dtor and implemented in the engine ?
I don't know if it is actually possible in PHP, but that works for several other languages (java, objC - in that case, the root object is explicit-, C# AFAR)
This would also bypass the error-level debate (no error would be thrown)
+1
--
Alexey Zakhlestin, http://twitter.com/jimi_dini
http://www.milkfarmsoft.com/
Hi folks,
Hi,
Well, that wasn't where I was expecting that thread to go, but to wrap it up
what do you think...
Is it too late to put this on the 5.4 roadmap for consideration?I'm assuming just the implicit ctor and dtor. Not all magic methods (not
now, at least).With your OK, Stas, I'd like to write up an RFC and put it on the Wiki.
- Andrew
The main problem with internal classes and ctors is that constructor
code can be placed at object init instead of in the actual ctor method.
It is actually safer to place it at object init, because then that code
is always executed and thus the internal object is not in a half
initialized state if the user overwrites the constructor and doesn't
call the parent.I'd rather have ctors/dtors explicitely defined in SPL. If they are
documented to exist, they should be explicitely defined. We can define
such NOOP methods globally, so that it is easy for internal classes to add
them.
This. In the short term, regardless of what happens with the code,
the documentation should reflect what is available in the language. If
a constructor is documented but not available to call then the
documentation needs to be clear about that. Any instances of this
currently in the docs should be a bug, it's an idea to report them
onto the bugs system.
As for what changes in the code, I think it would be nice for all
(SPL) classes to have a (global, noop) constructor even if nothing of
interest happens within it so that userland developers can happily,
blindly, call the parent constructor in their classes.
As an aside, do the changes made against #54384 have any impact here?
As far as implicitly ignore of the constructor, I believe we have enough
magic regarding ctors/dtors in the engine as it is.Best,
From what I can tell, whatever changes made to fix this bug, are independent
of #54384.
Bug #54384 happens when the parent ctor is not called. This bug is triggered
only when it is called.
I did a quick check of the code and that seems to be the case.
But the existence of that bug makes me think that having a __construct on
all SPL classes will be less confusing to the user.
So, on that note, back to square one. We can either:
- Implement a global SPL noop constructor to be added to all SPL classes
that don't have a constructor. - Change the documentation to reflect that some class don't have
constructors. Leave the code unchanged but inconsistent.
I already have the code for the first option done (just not checked in) and
that seems to be where most people are leaning anyway.
I can just check that in, close bug #54631 as "Fixed in SVN and needs to be
documented" and call it a day.
Then we can save the giant roadmap altering discussions about global
implicit __construct and/or global parent object for another day.
Any objections?
- Andrew
On Tue, May 17, 2011 at 4:39 AM, Peter Cowburn petercowburn@gmail.comwrote:
Hi folks,
Hi,
Well, that wasn't where I was expecting that thread to go, but to wrap
it up
what do you think...
Is it too late to put this on the 5.4 roadmap for consideration?I'm assuming just the implicit ctor and dtor. Not all magic methods (not
now, at least).With your OK, Stas, I'd like to write up an RFC and put it on the Wiki.
- Andrew
The main problem with internal classes and ctors is that constructor
code can be placed at object init instead of in the actual ctor method.
It is actually safer to place it at object init, because then that code
is always executed and thus the internal object is not in a half
initialized state if the user overwrites the constructor and doesn't
call the parent.I'd rather have ctors/dtors explicitely defined in SPL. If they are
documented to exist, they should be explicitely defined. We can define
such NOOP methods globally, so that it is easy for internal classes to
add
them.This. In the short term, regardless of what happens with the code,
the documentation should reflect what is available in the language. If
a constructor is documented but not available to call then the
documentation needs to be clear about that. Any instances of this
currently in the docs should be a bug, it's an idea to report them
onto the bugs system.As for what changes in the code, I think it would be nice for all
(SPL) classes to have a (global, noop) constructor even if nothing of
interest happens within it so that userland developers can happily,
blindly, call the parent constructor in their classes.As an aside, do the changes made against #54384 have any impact here?
As far as implicitly ignore of the constructor, I believe we have enough
magic regarding ctors/dtors in the engine as it is.Best,
Hi!
Personally, I really don't care for something like this. Would it be
caught by a __call declaration if one existed (since it is a call to
an undefined method)? Would you expect it to?
No and no. __call is not called for ctors, for obvious reasons (__call
is an object method, and before ctor is done the object is not ready).
It was always this way.
I'd rather see calls to non-existent methods generate a catachable
fatal error (rather than a hard fatal error that's currently thrown).
Personally, I like this "catchable fatal error" business less and less.
It's an awkward way of doing an exception with all exception downsides
and none of the upsides...
But silently ignoring a called function, something just doesn't sit
right about that...
We're already doing it :) Try:
class Foo {}
$a = new Foo();
You just ignored a non-existing ctor.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
No and no. __call is not called for ctors, for obvious reasons (__call is an
object method, and before ctor is done the object is not ready). It was
always this way.
It is called from constructors, just not for constructors:
class test {
public static function __callStatic($name, $args) {
printf("Static: %s\n", $name);
}
public function __call($name, $args) {
printf("Parent Instance: %s\n", $name);
}
}
class test2 extends test {
public function __construct() {
$this->bar();
parent::__construct();
}
public function __call($name, $args) {
printf("Instance: %s\n", $name);
}
}
$foo = new Test2();
Results in:
Instance: bar
PHP Fatal error: Cannot call constructor in...
While I do agree that it shouldn't call __call/__callStatic for
constructors, it does for other methods...
I'd rather see calls to non-existent methods generate a catachable
fatal error (rather than a hard fatal error that's currently thrown).Personally, I like this "catchable fatal error" business less and less. It's
an awkward way of doing an exception with all exception downsides and none
of the upsides...
That's fair, but if we buy that, let's have at least an option to
convert all errors to exceptions. That way there are no "catchable
errors", just exceptions for errors over a specified level (E_WARNING
for example)...
But silently ignoring a called function, something just doesn't sit
right about that...We're already doing it :) Try:
class Foo {}
$a = new Foo();You just ignored a non-existing ctor.
I guess that's fair. I just don't care for special-case logic in
general. It generates too many edge-cases. That's not saying this is
worth it or not, but just my preference...
Anthony
Martin Scotta
On Mon, May 16, 2011 at 4:10 PM, Anthony Ferrara ircmaxell@gmail.comwrote:
Personally, I really don't care for something like this. Would it be
caught by a __call declaration if one existed (since it is a call to
an undefined method)? Would you expect it to?
Although current PHP implementation treat them as method, it's important to
note that constructors are not methods.
$a = new Foo ();
$a->__construct(); // encapsulation broken
I'd rather see calls to non-existent methods generate a catachable
fatal error (rather than a hard fatal error that's currently thrown).
That way we can use an error exception to "catch" the fatal and
recover from it if necessary.But silently ignoring a called function, something just doesn't sit
right about that...On Mon, May 16, 2011 at 2:44 PM, Andrew Curioso andrewcurioso@gmail.com
wrote:I like that idea and I like that it works for userland classes as well.
+1
Do you think it should throw a warning, notice, or -- as you both
suggested
-- just silently succeed?2011/5/16 Johannes Schlüter johannes@schlueters.de
Hi,
I|d actuallz suggest a different option:
If a parent constructor is called but doesn't exist the engine should
ignore this. The same goes for destructors.This solution would also work for userland classes.
johannes
So, I ran across bug #54631
A fatal error is thrown if you try to call parent::__construct() from
a
subclass
of SplObjectStorage.I was going to close it as "expected behavior" since that is pretty
normal
if the parent class doesn't implement __construct().
Also, the docs don't list it as having a __construct() method.But then look at SplDoublyLinkedList (and a bunch of others). They are
documented
as having a __construct() method, yet it triggers a fatal error when
you
try
to call
"parent::__construct()" from a subclass' constructor .So it seems to me that there are two possible solutions:
- Update the docs to remove ::__construct() for classes that don't
have
one.- Make sure __construct() is implemented in all SPL classes * and
update
the
docs.
- Even if it is empty.
What's everyone thinking?
I'd be more than happy to add the constructors to the code where
needed,
I
just
want to make sure that it is the right move first.
- Andrew