Re: [PHP-DEV] Re: Why isn't base class constructors or destructors required to be called? (was: Re: [PHP-DEV] Return type hints)
When would the constructor be called automatically? I've used Delphi and you use the inherit verb (or inherited - long time ago - can't remember exactly). In PHP parent::__construct (though I think parent::__METHOD__ would be cleaner as this removes ambiguity on the actual name for all inherited methods). Well, let's look at C++, which I'm most familiar with. PHP is not C++ Ah, I was kind of waiting for that one... :) Yet, that says absolutely nothing about why PHP works the way it does. and speaking of constructors and destrcutors PHP goes morethe Delphi way. If constructors/destructors are not the PHP way, then why even have them? We do not claim to follow any other language precisely, PHP is it's own language with its own feature set. 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? Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Why isn't base class constructors or destructors required to be called? (was: Re: [PHP-DEV] Return type hints)
From: Marcus Boerger [EMAIL PROTECTED] PHP is not C++ and speaking of constructors and destrcutors PHP goes morethe Delphi way. I'd also like to know _why_ constructors/destructors are less fit for PHP, than these other languages? How can you be sure that objects of a class are properly initialised, and that they clean up after themselves? (Yes, I know the runtime cleans up after them, at script termination, if want to be sloppy, but that still doesn't cover the constructor case) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Why isn't base class constructors or destructors required to be called? (was: Re: [PHP-DEV] Return type hints)
Well, PHP is a loosely typed language. You have much more freedom when you write a code. Constructors are not an exception. It is very convinient that you may not call the parent constructor and many people do it, believe me! And also the flag for the internal classes that has been discussed is maybe enough for PHP. 2006/9/15, Terje Slettebø [EMAIL PROTECTED]: From: Marcus Boerger [EMAIL PROTECTED] PHP is not C++ and speaking of constructors and destrcutors PHP goes morethe Delphi way. I'd also like to know _why_ constructors/destructors are less fit for PHP, than these other languages? How can you be sure that objects of a class are properly initialised, and that they clean up after themselves? (Yes, I know the runtime cleans up after them, at script termination, if want to be sloppy, but that still doesn't cover the constructor case) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What's wrong with dl?
Michael B Allen wrote: Our CLI module installer uses dl() to manually load the module and validate some basic functionality. This is a very nice feature and I'm disappointed to see it has been deprecated. Will there be any equivalent functionality moving forward? The extension directive is clumsey in this scenario because it would require running a separate script. dl() is scheduled to be removed from all other SAPI's. I believe that there are no current plans to deprecate it from the CLI version of PHP. Edin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Why isn't base class constructors or destructors required to be called? (was: Re: [PHP-DEV] Return type hints)
From: Marian Kostadinov [EMAIL PROTECTED] Well, PHP is a loosely typed language. You have much more freedom when you write a code. Constructors are not an exception. It is very convinient that you may not call the parent constructor and many people do it, believe me! Why would you not call the base class constructor/destructor? Could you give an example? Regards, Terje 2006/9/15, Terje Slettebø [EMAIL PROTECTED]: From: Marcus Boerger [EMAIL PROTECTED] PHP is not C++ and speaking of constructors and destrcutors PHP goes morethe Delphi way. I'd also like to know _why_ constructors/destructors are less fit for PHP, than these other languages? How can you be sure that objects of a class are properly initialised, and that they clean up after themselves? (Yes, I know the runtime cleans up after them, at script termination, if want to be sloppy, but that still doesn't cover the constructor case) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Why isn't base class constructors or destructorsrequired to be called?
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
Re: [PHP-DEV] Re: Why isn't base class constructors or destructors required to be called? (was: Re: [PHP-DEV] Return type hints)
On 9/15/06, Terje Slettebø [EMAIL PROTECTED] wrote: From: Marcus Boerger [EMAIL PROTECTED] PHP is not C++ and speaking of constructors and destrcutors PHP goes morethe Delphi way. I'd also like to know _why_ constructors/destructors are less fit for PHP, than these other languages? Nobody said that. Marcus said PHP takes a more Delphi-like approach rather than a C++-like approach. PHP following some other language rather than your language of choice doesn't mean that its designed wrong. -- --Robert Deaton
Re: [PHP-DEV] What's wrong with dl?
On Fri, 15 Sep 2006 09:10:49 +0100 Edin Kadribasic [EMAIL PROTECTED] wrote: Michael B Allen wrote: Our CLI module installer uses dl() to manually load the module and validate some basic functionality. This is a very nice feature and I'm disappointed to see it has been deprecated. Will there be any equivalent functionality moving forward? The extension directive is clumsey in this scenario because it would require running a separate script. dl() is scheduled to be removed from all other SAPI's. I believe that there are no current plans to deprecate it from the CLI version of PHP. Ah, good. Thanks. Mike -- Michael B Allen PHP Active Directory SSO http://www.ioplex.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Two modules w/ different instances of same lib causes crash
My extension (plexsso.so) is dymanically linked with a library. That library (libplexsso.so) is a statically linked collection of libs including a custom version of Heimdal Kerberos (libkrb5.a). I have found that if another module is linked with the stock Heimdal (e.g. pgsql.so dynamically in this case) some symbol mixing occurs and the application crashes. Can two modules use different instances of the same library? Before I go try to become an expert in linking and the Linux loader can anyone give me advice as to how to I might workaround (for Linux at least)? Mike -- Michael B Allen PHP Active Directory SSO http://www.ioplex.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: wudicgi
Managing the source code of PEAR Crypt_XXTEA. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Two modules w/ different instances of same lib causes crash
RTLD_DEEPBIND fixes this problem using a test program and two minimalistic DSOs to emulate the namespace clash problem. But I see PHP has support for RTLD_DEEPBIND: # if defined(RTLD_GROUP) defined(RTLD_WORLD) defined(RTLD_PARENT) ... # elif defined(RTLD_DEEPBIND) ... # else ... # endif On my Linux glibc 2.3 systems RTLD_DEEPBIND is chosen. So now, I have to wonder why my customer had a problem in the first place. Based on the above macros, is it possible that RTLD_DEEPBIND could NOT be chosen? Mike On Fri, 15 Sep 2006 11:43:56 -0400 Michael B Allen [EMAIL PROTECTED] wrote: My extension (plexsso.so) is dymanically linked with a library. That library (libplexsso.so) is a statically linked collection of libs including a custom version of Heimdal Kerberos (libkrb5.a). I have found that if another module is linked with the stock Heimdal (e.g. pgsql.so dynamically in this case) some symbol mixing occurs and the application crashes. Can two modules use different instances of the same library? Before I go try to become an expert in linking and the Linux loader can anyone give me advice as to how to I might workaround (for Linux at least)? Mike -- Michael B Allen PHP Active Directory SSO http://www.ioplex.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Two modules w/ different instances of same lib causes crash
On Fri, 15 Sep 2006 15:23:16 -0400 Michael B Allen [EMAIL PROTECTED] wrote: So now, I have to wonder why my customer had a problem in the first place. Based on the above macros, is it possible that RTLD_DEEPBIND could NOT be chosen? The customer is using 4.3.4 which did not have the RTLD_DEEPBIND patch so that explains it. Problem solved. You guys are good :- Does anyone happen to know what version the RTLD_DEEPBIND patch was shipped in? Is there a way to tell from look at http://viewcvs.php.net/viewvc.cgi/ ? Mike -- Michael B Allen PHP Active Directory SSO http://www.ioplex.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
