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).
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.
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
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
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?
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.
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
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
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
regards
--
o----------0-¬---------O-·---¬----o---®-----o o O ° .
| http://www.kiffen.de | pRoteçt y0ur bRaín |0 O ° ¤ °
·
0°·³°²'²³-¹'³´³°^°³~³²³°'³²²¨³²^³¹³²°²³`³º³°Þ °
o © ° . ·
| psychedelic experience | gott@kiffen.de | O ° o °
o-¬--o--0-----©-·--O-----o-----0-¤----------o 0 ° · ° . ¤ ·