RE: [PHP4BETA] OO Destructors

> -----Original Message----- > From: Colin Putney [mailto:cputney@whistler.net] > Sent: 10 August 1999 05:09 PM > To: Samuel Liddicott > Cc: zeev@zend.com; Manuel Lemos; php3@lists.php.net; sander@3dnews.net; > php4beta@lists.php.net > Subject: [PHP4BETA] OO Destructors > > Samuel Liddicott wrote: > > > I'm with Manuel on this. Delphi has destructors but no > > copy-constructors. Destructors are very useful, why do they suggest > > the need for copy constructors and other such stuff? > > This has to do with the way objects are implemented under the hood. > I'm not familiar with the innards Delphi, but I suspect that it uses > straight pointers rather than object references as PHP does. Yep, although it hides the fact that they are pointers. So basically they look like objects but you can ONLY pass by reference. > As I understand it, PHP4 also lets you have several variables that > reference the same object. This can be done explicitly by the > programmer, but the Zend will also do it at other times to optimize > memory usage. At the same time, because there are no pointers in PHP, > a variable *must* reference a value. It can't dangle. > > So lets say you have an object referenced by several variables. When > does the destructor get called? It can't happen when just one of the > references is pointed somewhere else, or falls out of scope (or > whatever, ie. the reference count is decemented) because that leaves > several other references effectively dangling - they reference a > destroyed object. Quite right. > On the other hand, it can't be called only when the reference count > equals zero, because then you have the possibility that Zend's memory > optimizations could cause the destructor not to get called when the > programmer expects. Why? Daft programmer. Surely he only expects it to get called when the reference count reaches zero. I hope we aren't making things more complicated in an effort to make it look simpler than it is. > If two objects that are ostensibly distinct > happend to end up as two references to the same internal > representation, then the destructor will only get called once. That scares me. I think it should not be so. > One way around this is to make a copy of the object whenenver the > reference count is decremented, and then call the destructor on that. Nope. > Then you're assured that the destructor will be called exactly once > for each reference to the object, and you get the advantage of > reference counting while maintaining the effect of separately stored > instances. But thats no fun. Haveing multiple references is fun. > This works fine for scalar variables, but objects are more complex. > They might have allocated additional resources like open network > sockets, file descriptors, database connections etc. So if you just > copy all the values, you end up with objects that share these > resources. If these resources get freed in the destructor, as the > often are, then the other copies of the object will be corrupted. > They'll have invalid file descriptors, connection ids etc. Yep, we shouldn't do it like that. We should only call the destructor when it is finally destroyed. > So if you're going to copy objects, you can't let the PHP runtime > handle it because it doesn't have enough information about the object > to do it safely. It has to be handled explicitly by the programmer, > ie. you need copy constructors. Lets just not copy objects. Consider it the OLE way (PHP is going to go a bit ole, right?) There are no sneaky duplications of ole objects. Objects are only destroyed when there are no references left. This is a nice way to do it. > I have to agree with Zeev that the convenience of destructors isn't > worth the requirement for copy constructors. I agree with THAT. > On another level, it > seems to be too C++ish to me, not at all in keeping with the flavour > or the overall design of PHP. It seems very Delphi-ish to me and entirely in flavour of the language. All we want is a function to be called when the object is released, which implies not having to seperate reference counters to the same object memory-image (which seems common sense)? Why do we have multiple refernce counts pointing to the same object-in-memory. I heard is "part of the optimization" but it seems the only obstacle to decent destructors, and therefore possibly a little too optimized? What is the reason? > PHP is an extremely dynamic language, > and I see PHP objects more like JavaScript/Dylan/NewtonScript objects. I liked Dylan, Mindy was my favourite flavour but it died in favour of a Dylan->C converter. > What I would like to see is a way to add functions to PHP objects at > runtime. Zeev, is this possible in PHP4? If not, is it feasible to > add? *sweat* gosh! *gulp* SAm