Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:19521
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <1A.05.54476.F3F38434@pb1.pair.com>
To: internals@lists.php.net
Date: Sat, 08 Oct 2005 23:50:56 +0200
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
MIME-Version: 1.0
References: <00A2E2156BEE8446A81C8881AE117F192C15D3@companyweb>
In-Reply-To: <00A2E2156BEE8446A81C8881AE117F192C15D3@companyweb>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: return /* by reference */ new Foo() in PHP4
From: oliver.graetz@arcor.de (=?ISO-8859-1?Q?Oliver_Gr=E4tz?=)

Matthias Pigulla schrieb:

> So, in case of "return new", wouldn't it make sense to remove the
> warning as the code is 'legal'? And please, don't start a new "it's just
> a friendly notice" flame war.

Throwing a notice here is complete nonsense. All thinkable languages use
this coding style of "return new". If I return a reference to something
new and there's no name for it yet then a temporary internal name for it
has to be created until the object is given a real name or it is no
longer referenced. This is valid for all "only variables can be returned
by reference" cases where the object originates from userspace.

> The bug describing this is #33679, marked as bogus with no further
> explanation.

I had a similar experience with http://bugs.php.net/bug.php?id=34783
which tells that with objects implementing ArrayAccess usage of

$object['index_using_the_interface']['subindex_for_index_that_is_array']

can't be made to work since 5.1. First of all, "won't fix" would have
been the correct response instead of "bogus" since a very similar
problem was marked "won't fix". But there are two things very
problematic with this:

- This worked perfectly in 5.0.3 (I didn't use 5.0.4 so I don't know
  how 5.0.4 reacts).
- You mustn't create an interface that pretends to mimic arrays and
  then make it impossible to fully simulate array behaviour.

The explanation for marking the bug bogus was "IT IS IMPOSSIBLE TO HAVE
ARRAYACCESS DEAL WITH REFERENCES.". Then why did this work in 5.0.3?
Okay, perhaps because of a more lax way of parsing the interface
definition. But then this definition was false in the first place and
should be corrected to support references. And if this is out of
question then at least some workaround has to be implemented to support
the sub-array-syntax as this has nothing to do with references from a
user's point of view.

Think a few years into the future with ArrayAccess implementations all
over the place and people trying to use them as arrays. Because these
implementations are hidden in frameworks people will totally freak out
because sometimes $a[1][2] works and sometimes they get a totally
incomprehensible "Objects used as arrays in post/pre increment/decrement
must return values by reference" as fatal error when using such simple code.

If they can't make the ArrayAccess to work like real arrays then it
would be a better way to completely dump it (or lock it against
implementation in userspace) instead of letting inconsistent behaviour
creep into the language concepts.

But, like with your bug, the bogusing bot is quite quick these days
where just CLOSING mem leaks has priority over FIXING them from a PHP
user's point of view. Perhaps the PHP coders should keep _all_ PHP code
from being executed as this would certainly close every thinkable leak.

It's not wise having users turn their back on key features of 5.x when
the switch from 4.x to 5.x hasn't even really started.


AllOLLi
____________
"Your DNA must cry itself to sleep at night."
[Coupling]