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

At 09:34 PM 8/17/00 +0200, André Langhorst wrote:

1.) The new constructor always returns references or alternatelly

        we would need a syntax like &new

I can´t imagine that there´s an unnecessary copy between new foo; and the assignment I really can´t imagine, please anyone, tell me that this is not true (also watch my last post on this topic).

There is no unnecessary copying. new() returns the object and if you have something like $obj = new foo(); $obj is changed to point to the returned object.

2.) The assignment operator handles references as references not

        as the value of the reference.

Well, this is an option and another one, functions *always* should return references, there´s no impact on this (I can imagine right now, I´ve sticked an & to *all* my current functions, and they´re still working as intended). The function has been executed, the value will be destroyed, why not return a reference then, to keep it alive and avoid unnecessary copying. Correct me if I´m wrong guessing PHPs current behaviour.

As it is a reference counting system this is a bit more complicated than it looks. If you return a regular variable then no copying is done (just reference count is increased). But if you return a reference by value then it is copied if some other variable is pointing at it. This is so that the calling function won't change the value of that reference (you need to explicitly mark the function to return a reference ). Example which doesn't include function calls: $a = &$b; $c = $a; $c = 5; Eventhough $a is a reference you don't want the changing of $c to change $a nor $b. This also applies to: $c = foo(); You wouldn't want changing $c on the outside to change the value returned if it is referenced from other scopes. It's a bit complicated to explain, also we might be able to optimize it a bit more. I know I didn't explain it too well but I'm in a rush :)

1) The constructor works as any other member function!

well not really, you can´t return any value from it, of course you *could* return a value if you´re overwriting $this from within the constructor, it really works, but you´ll be killed if you´re telling someone that you´re doing this

Right I'll shoot you myself :)

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!!!!!!!

well, I still won´t believe that it´s true, but I don´t know, I´ll start some performance tests

Not anymore although it used to.

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.

How did you test?

PHP still isn't a language where you would implement complex binary trees and linked lists in. There is limited support for referencing but it's not like C++.

        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).

If you´ve concrete proposals feel free to submit patches or discuss it on the list.

At the end of the request "leaks" from circular references are freed. I can't think of scenarios where you would be creating too many such references in a way this would cause problems for you during script execution unless you really try. Having circular references "leak" (although they get cleaned up after each request) is what happens in reference counting systems. We don't want to add a garbage collector like in Java. That would suck.

4) My definition of a bug in short form is 'unexpected behaviour'.

in fact I´d say it is "unexpected deviation from developer-expected behaviour", mostly developer-expected-behaviour should be close to user-expected-behaviour, sometimes it isn´t the case (eg. floor((0.7+0.1)*10) and it still doesn´t qualify as a "bug", this need documentation then

        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(..);
        THAT IS CRAZY - sorry.

totally agreeing, I think documenting this will no improve the situtation, users won´t understand why they should do this (me included), I´d love some expert comment on this, if it´s really the case what I´ve tried to find out in my last post on this topic

I have to think about this one a bit more. We might be able to improve the situation a bit.

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!

that´s already planned and I don´t know if it has sth. do to with it

It is planned but we first want 4.0.x to be stable. I think you can expect this in 4.1.x or 5.0.x? Whatever it will be called :)

6) Shallow copies can be avoided - I have not yet found any computer science

        specialist you call's shallow copies a good language construct!!!!

well, I´m waiting on some expert comment from andi or zeev, but as stas mentioned, it ought to be supported sometimes, but not currently and I don´t think they´ll break their current work before relasing 4.0.2, we want a stable release and even then I don´t know if it´s the primary objective, PHP is stable and working, perhaps they don´t see a reason to act quickly

In most cases reference counting takes care of not doing too many shallow copies but if it is wrong not to do it semantically it is done. Andi --- Andi Gutmans <andi@zend.com> http://www.zend.com/