RE: [PHP3] RE: [PHP4BETA] Re: [PHP3] Re: [PHP4BETA] Re: [PHP3] OO

> -----Original Message----- > From: Zeev Suraski [mailto:zeev@zend.com] > Sent: 10 August 1999 05:15 PM > To: Samuel Liddicott; Manuel Lemos > Cc: php3@lists.php.net; sander@3dnews.net; php4beta@lists.php.net > Subject: [PHP3] RE: [PHP4BETA] Re: [PHP3] Re: [PHP4BETA] Re: [PHP3] OO > > $a = new object; > $b = $a; // $a and $b now point to the same place in > memory, but if > one of them is changed, > // they're separated and no longer point to the same > memory, so that changes made to > // $a won't be applied to $b and vice versa > // lets say the script ends here, and $a and $b are destroyed. ouch! This is scary as Shannon points out. Surely I want them to keep pointing to the same object. Hey - I'm me, I KNOW I want them to keep pointing to the same object. If I instantiate a class I might have many references to it, I want one update to be visible from all sides. If I didn't, I would have created another instance. > Lets say $a > holds a resource, be it > // an open file, an open transaction handle, or whatever else you > can think > of. You would obviously > // not want to deallocate the resource more than once, so it's > obvious the > destructor shouldn't run Quite right, I just didn't realise about that "duplicate object on write" trick, which I am a but worried about. > // twice on both $a and $b, but just once on their related object > // But, what if the resource $a holds is no longer the same as > the resource > $b holds? What if > // you changed the resource $b holds through one of its methods or even > from the outside world? > // Then you would want the destructor to run twice, on both $a and $b All valid stuff, I just wouldn't want those circumstances to ever come about whether or not I was using destructors. It seems like this implicit copy-constructor thingy is a problem. > The inherent problem with adding destructors to PHP results from: > 1. Objects aren't always allocated with 'new', but can be copied around > using standard assignments THIS scares me. > To change this, we would have to make it impossible to copy > around objects, > including sending them to functions, etc, except for copying > by-reference. I thought (and wish) this was how it worked. > All object instanciations would have to be done using > 'new'. This is a *major* downwards incompatibility, and extremely > inefficient to implement since it would require a lot of run-time work to > determine what kind of assignments should be conducted every time. I can see *that* problem. But this sneaky on-the-fly copy scares me. I suspose under Delphi I am used to bandying around pointers to objects (although I stress, just like PHP, they DON'T look like pointers, they look like actual objects [unlike c]) and this is why it has taken me by surprise. Can't we just admit that objects are only passed by reference. After all, who would want to pass an object not by reference? [Perhaps as a slightly intelligent record?] Hmmm. Sam