Hi Christian.

Thanks for your reply, but I would appreciate it if people read my posting
properly, before replying: I have _not_ asked for this to be changed, I have
just asked for _reasons_ for the current situation, and pointed out
potential problems with it. I think that's reasonable request.

Yes, having to explicitly call the base class constructor/destructor allows
you to be conscious about calling it. It also allows you to forget it, in
the same way that returning error codes (rather than throwing exceptions)
means you have to be conscious about handling them. Unfortunately, as doing
that requires additional code, it's often not done, either consciously
("This function probably always succeeds..."), or simply forgotten.

If a base class changes, from not requiring a constructor/destructor call,
to requiring it, it also means that _all_ client code (much of which you may
not control or know of) will have to be changed, as well. Failure to do so
leads to "silent bugs". The same goes for functions changing to return error
codes.

Not checking return codes leads to brittle and buggy software, and problems
from this is well known, which is one of the reasons for exceptions (which
_can't_ be ignored). Or would you perhaps like catching exceptions to be
optional, as well...? You know, a little more "flexibility"... Having to be
"conscious" that you catch it, or else, you'll never know that you've
actually got a bug...

Regards,

Terje

>From: "Christian Schneider" <[EMAIL PROTECTED]>
>To: "Terje Slettebø" <[EMAIL PROTECTED]>
>Sent: Friday, September 15, 2006 11:38 AM
>Subject: Re: [PHP-DEV] Re: Why isn't base class constructors or
destructorsrequired to be called?

> Terje Slettebø wrote:
> > Naturally, but is it unreasonable to think that there's a reason for the
way
> > things work in PHP...? And to ask _why_ PHP doesn't let you ensure that
a
> > class has its constructor/destructor called? Why implement
> > constructors/destructors in such a way that they may - or may not - be
> > called? "Do you feel lucky?"
>
> The main reason I see: Simplicity, i.e. less magic in the language.
>
> PHP programmers are taught to a) call the parent contructor if needed
> and b) not to rely on when destructors are called.
>
> Adding a parent::__construct/destruct call is no effort and allows to be
> conscious about when to call it (after or before you initialized some
> stuff) or how to call it (modify the parameters for it). Like it or not
> but I never found it a big limitation so far.
>
> But the main reason I'm writing this email is to tell you that it the
> minds here are set and you won't be able to change that so it's probably
> better to leave it at that.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to