Re: RE: PHP 4.0 Bug #6193 Updated: new object makes a shallow copy

From: Date: Fri, 18 Aug 2000 19:47:45 +0000
Subject: Re: RE: PHP 4.0 Bug #6193 Updated: new object makes a shallow copy
References: 1  Groups: php.dev 
Request: Send a blank email to php-dev+get-29517@lists.php.net to get a copy of this message
On Thu, 17 Aug 2000, Heinz Doerr wrote: > Waldschrott, > > I completely agree to your statement below. > > Plus, it's trist. > One single change and many problems in PHP oo behaviour would disapeare. > > The change: > 1.) The new constructor always returns references or alternatelly > we would need a syntax like &new This is pretty meaningless. > 2.) The assignment operator handles references as references not > as the value of the reference. This isn't the intended semantics of references. > The benefit: > 1) The constructor works as any other member function! But it isn't, it's not supposed to be, and it doesn't behave like any other function by both definition and in other languages. > 2) The performance of an object constructor get's MUCH faster. > From my e-mail discussion yesterday with Stanislav, I understood: > $myinstance= new MyClass(...); > This simple instruction generates from my understand 2 or 3 > shallow copies in the background before it finishes!!!!!!! There aren't any 'shallow copies'. > 3) That's may be most important: > PHP would have no problems with circular references anymore. > I have tested it - PHP can handle circular references w/o problems. > Surely enough - as with any other language e.g. Java, C++, Perl - > the programmer of circular referenced data structure must carefully > clean the structure (destruct). Circular references don't have anything to do with constructors, or with return values from functions. You can easily create a circular reference situation without using objects or functions, which means that your suggested changes simply can't solve this (I didn't try to understand why you think they solve it, because by definition, they don't :) > 4) My definition of a bug in short form is 'unexpected behaviour'. > And I make any bet, that most - maybe almost anyone - doesn't > expect the current behaviour. > e.g. I can't understand that a language push me to declare return > by reference twice: > function &member(..) { ... }; > $x= $member(..); Well, PHP is very different from the languages you compare it with - very little is known in compile time. Since assigning a reference and assigning a value results in different code being generated, and since it's very difficult to avoid this. It's probably not impossible, and hopefully we'll manage to improve this in the future. > 5) I guess that the construct$obj1(..)->member1(..)->member2(..) > could than easily be supported. > Today I need to write: $obj2= &$obj1->member1(); $obj2->member2(); > I believe, that this not working statement in PHP show's that > there is something broken internally! (This is bug #4 = buy the way! No, it doesn't show that something is broken internally. This functionality simply hasn't been implemented. The -> operator in PHP 4.0 requires an object for its lvalue, and not an object expression. We'll probably improve that in the future. > 6) Shallow copies can be avoided - I have not yet found any computer science > specialist you call's shallow copies a good language construct!!!! It's not a language construct... What do you mean? PHP currently behaves in the way we implemented it to behave. Zeev

« previous php.dev (#29517) next »