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 ).
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 :)
I still don´t get what´s happening exactly using reference returning
functions, as I understood now...
1) normal function return and normal assignment
-> returns "copy" with increased ref-count, it´s in fact no copy (and no
doubla copy at all)
2) reference function return and normal assignment
-> returns a reference, but makes a copy under some circumstances (I did
not get) that results in an additional copy, thus it does make no sense
3) normal function return and reference assignement
-> no effect, thus=1 or same as 2?
4) reference function return and reference assignment ->
-> this is the expected behaviour of (2) and results the returned value
(reference?) to be referenced by the reference to assign to
confusing,
but I (we) will patiently wait on a better explication, perhaps with
two-sides, one with meaning for the userland and one with the internal
handling (like using ref-counts...) *IF* possible
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.
I would be interested in how big these leaks are and on what its size
depends and how much and when they´re created. Then I´d be able to
figure out at which point a personal garbage collector would make sense.
I have to think about this one a bit more. We might be able to improve
the situation a bit.
would you please then tell us if you´ve finished thinking, that´ll be great
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 :)
ok. then 4.1.x or 5.0.x follows 4.0.2 ;)