Hello,
Dmitry committed a fix earlier to ignore the & in the statement above. I
think this is not a good thing to do as it's simply conceptually wrong.
The first thing is that ignoring syntax without issuing a warning is
dubious because people might think it does actually work, and secondly
because I think that the code above is wrong anyway - somewhat in the
same way that "$this = new foo();" is wrong.
There is never any need to assign $this by reference, nor to pass it by
reference to a function as it's an object anyway, making the references
pointless - I would even go as far as disallowing passing $this by
references to a function - where the reference has to be ignored again,
otherwise it allows you to chantge $this to a different object with:
class Foo {
function byRef(&$f) {
$f = new Bar();
}
function modifyThis() {
$this->byRef($this);
}
}
I think we should prevent people from writing syntax like this, as it is
not obvious what is going to happen. This means that we should revert
Dmitry's patch.
regards,
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
Hello Derick,
Monday, October 3, 2005, 3:09:22 PM, you wrote:
Hello,
Dmitry committed a fix earlier to ignore the & in the statement above. I
think this is not a good thing to do as it's simply conceptually wrong.
The first thing is that ignoring syntax without issuing a warning is
dubious because people might think it does actually work, and secondly
because I think that the code above is wrong anyway - somewhat in the
same way that "$this = new foo();" is wrong.
There is never any need to assign $this by reference, nor to pass it by
reference to a function as it's an object anyway, making the references
pointless - I would even go as far as disallowing passing $this by
references to a function - where the reference has to be ignored again,
otherwise it allows you to chantge $this to a different object with:
class Foo {
function byRef(&$f) {
$f = new Bar();
}
function modifyThis() { $this->byRef($this); }}
I think we should prevent people from writing syntax like this, as it is
not obvious what is going to happen. This means that we should revert
Dmitry's patch.
Same here.
Best regards,
Marcus
Hmmm.... I agree about the reassigning of $this, but not the passing of
$this by ref.
Example:
Class A {
public $tableName = 'Forum';
public $childObject;
public function __construct() {
$this->childObject = new B($this);
}
}
Class B {
private $parent;
public function __construct(&$parent) {
$this->parent = &$parent;
}
public function get_stuff() {
// Generate SQL useing the parents global table name settings
etc....
}
}
On Mon, 3 Oct 2005 15:21:38 +0200
Marcus Boerger helly@php.net wrote:
Hello Derick,
Monday, October 3, 2005, 3:09:22 PM, you wrote:
Hello,
Dmitry committed a fix earlier to ignore the & in the statement above. I
think this is not a good thing to do as it's simply conceptually wrong.
The first thing is that ignoring syntax without issuing a warning is
dubious because people might think it does actually work, and secondly
because I think that the code above is wrong anyway - somewhat in the
same way that "$this = new foo();" is wrong.There is never any need to assign $this by reference, nor to pass it by
reference to a function as it's an object anyway, making the references
pointless - I would even go as far as disallowing passing $this by
references to a function - where the reference has to be ignored again,
otherwise it allows you to chantge $this to a different object with:class Foo {
function byRef(&$f) {
$f = new Bar();
}function modifyThis() { $this->byRef($this); }}
I think we should prevent people from writing syntax like this, as it is
not obvious what is going to happen. This means that we should revert
Dmitry's patch.Same here.
Best regards,
Marcus--
====================================================================
Richard Mann (Programmer)
-=
Skynet Internet Services
a: 8 Premier Court
Boarden Close
Moulton Park
Northampton
NN3 6LF
-=
t: 0845 1 20 65 90 (General)
t: 0845 1 24 44 00 (Sales)
f: 0845 1 20 65 91
w: http://www.sky.net.uk/
-=
D I S C L A I M E R
Statements and opinions expressed in this e-mail may not represent those
of the company.
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you
received this in error, please contact the sender immediately and delete
the material from any computer.
Hmmm.... I agree about the reassigning of $this, but not the passing of
$this by ref.
Why are you passing an object be reference? Never heard that in PHP 5
objects are always references?
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
Hmmm.... I agree about the reassigning of $this, but not the passing of
$this by ref.Why are you passing an object be reference? Never heard that in PHP 5
objects are always references?
Amazing how fast the assumption has become that passing object values in
PHP5 is identical to passing the object by reference. It is not the
same, there are subtle differences. Either way I'm not weighing in on
the $ref = &$this issue, only that $obj = $someObj is NOT the same as
$obj = &$someObj.
<?php
class FooA{}
class FooB{}
$a = new FooA();
$b = new FooB();
$blah1 = &$a;
$blah2 = &$blah1;
$blah1 = $b;
print_r( $blah2 );
unset( $a, $b, $blah1, $blah2 );
$a = new FooA();
$b = new FooB();
$blah1 = $a;
$blah2 = $blah1;
$blah1 = $b;
print_r( $blah2 );
?>
Cheers,
Rob.
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'
Either way I'm not weighing in on the $ref = &$this issue
Actually, I think I will.
I think $ref = &$this is perfectly legal and
I think $this = &$ref or $this = $anything is perfectly illegal.
Cheers,
Rob.
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'
On Mon, 3 Oct 2005 15:09:22 +0200 (CEST)
derick@php.net (Derick Rethans) wrote:
I think we should prevent people from writing syntax like this, as it
is not obvious what is going to happen.
I agree too.
The question is only about how to prevent users to do that without
breaking "everything" out there.
I would like to go with a notice for the next stable release (both
5.0.x and 5.1.0) and see when we can make it as a fatal error,
something like 5.2 or so. HEAD can keep the error as it was.
--Pierre
Derick Rethans wrote:
pointless - I would even go as far as disallowing passing $this by
references to a function - where the reference has to be ignored again,
This would be needed to have something like
function setfoo(&$obj)
{
$obj->foo = 42;
}
[...]
$other->setfoo($this);
in a way which also works for PHP4.
a) I know that you now are going to bash me for mentioning PHP4
b) No, I don't think this is very common or elegant
But disallowing it might break existing code, no?
- Chris
Hello Christian,
php 4 code is wrong in this and we don't want to support the errors
forever.
marcus
Monday, October 3, 2005, 3:39:00 PM, you wrote:
Derick Rethans wrote:
pointless - I would even go as far as disallowing passing $this by
references to a function - where the reference has to be ignored again,
This would be needed to have something like
function setfoo(&$obj)
{
$obj->foo = 42;
}
[...]
$other->setfoo($this);
in a way which also works for PHP4.
a) I know that you now are going to bash me for mentioning PHP4
b) No, I don't think this is very common or elegant
But disallowing it might break existing code, no?
- Chris
Best regards,
Marcus
Marcus Boerger wrote:
php 4 code is wrong in this and we don't want to support the errors
forever.
Programming is like sex: One mistake and you have to maintain it for the
rest of your life (-:C
Sometimes I wish I would have insisted more in Nov. 1999 when I brought
up the reference vs. cloning issue for PHP4 beta. Oh well...
Anyway, if you break compatibility with PHP4 you risk that fewer
people migrate to it, not more. Lots of PHP4 code is out there and easy
migration is key. That's why I'd advocate an E_STRICT plus disallow it
in PHP7 (or PHP8 ;-)).
- Chris
Hello Christian,
Monday, October 3, 2005, 4:29:19 PM, you wrote:
Marcus Boerger wrote:
php 4 code is wrong in this and we don't want to support the errors
forever.
Programming is like sex: One mistake and you have to maintain it for the
rest of your life (-:C
Sometimes I wish I would have insisted more in Nov. 1999 when I brought
up the reference vs. cloning issue for PHP4 beta. Oh well...
Anyway, if you break compatibility with PHP4 you risk that fewer
people migrate to it, not more. Lots of PHP4 code is out there and easy
migration is key. That's why I'd advocate anE_STRICTplus disallow it
in PHP7 (or PHP8 ;-)).
E_STRICT in 5.0, 51 is the least thing we need to do and probably we should
simply stop supporting 4.4 otherwise we never have our user base upgrade.
Best regards,
Marcus
Marcus Boerger wrote:
E_STRICTin 5.0, 51 is the least thing we need to do and probably we should
simply stop supporting 4.4 otherwise we never have our user base upgrade.
While we would love to upgrade to PHP5 there is one killer for us so far:
None of the open caches (Zend cache is not an option for us) work
reliably. They a) start crashing or behaving weird after a while and b)
don't work on 64bit systems (yes, some of our non-PHP code would profit
from 64bit) when we tried recently.
So switching from PHP4/mmcache to PHP5 would mean we have to buy more
machines and we'd still get higher latency which is no good.
George: APC did quite well but started doing weird things (weird
warnings, not crashing though) after a while. If you have any hints for
me on how to provide you with information necessary to fix the problem,
I'd be glad. I will install 3.0.8 on my development machine again and
try to describe what happens.
Please accept that there are and will be real people with real problems
with PHP5 out there for a while,
- Chris
Hello Christian,
Tuesday, October 4, 2005, 10:14:05 AM, you wrote:
Marcus Boerger wrote:
E_STRICTin 5.0, 51 is the least thing we need to do and probably we should
simply stop supporting 4.4 otherwise we never have our user base upgrade.
While we would love to upgrade to PHP5 there is one killer for us so far:
None of the open caches (Zend cache is not an option for us) work
reliably. They a) start crashing or behaving weird after a while and b)
don't work on 64bit systems (yes, some of our non-PHP code would profit
from 64bit) when we tried recently.
So switching from PHP4/mmcache to PHP5 would mean we have to buy more
machines and we'd still get higher latency which is no good.
George: APC did quite well but started doing weird things (weird
warnings, not crashing though) after a while. If you have any hints for
me on how to provide you with information necessary to fix the problem,
I'd be glad. I will install 3.0.8 on my development machine again and
try to describe what happens.
Please accept that there are and will be real people with real problems
with PHP5 out there for a while,
Hm, sounds like a real problem then. Are you aware that in the last weeks
alot of work has been done to have APC support PHP 5 and especiall 5.1?
I think everyone involved will continue to do so, so perhaps you should try
it on a regular basis and help with some bug hunting?
Best regards,
Marcus
a) I know that you now are going to bash me for mentioning PHP4
b) No, I don't think this is very common or elegantBut disallowing it might break existing code, no?
Yes, but thinking that PHP 4 "OO" code runs on PHP 5 is an illusion
anyway.
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
Hello Derick,
Tuesday, October 4, 2005, 9:41:39 AM, you wrote:
a) I know that you now are going to bash me for mentioning PHP4
b) No, I don't think this is very common or elegantBut disallowing it might break existing code, no?
Yes, but thinking that PHP 4 "OO" code runs on PHP 5 is an illusion
anyway.
I can only emphasize this.
Best regards,
Marcus
Hi Marcus Boerger, you wrote:
Hello Derick,
Yes, but thinking that PHP 4 "OO" code runs on PHP 5 is an illusion
anyway.I can only emphasize this.
Frankly, this is not the PHP users fault at all.
If PHP5 would have been the PHP5 many had expected and
had broken lots of more things and if you (not tied to
one person) would have educated users about that, there
wouldn't be such "illusions" at all.
Regards,
Michael - < mike(@)php.net
Derick Rethans wrote:
Yes, but thinking that PHP 4 "OO" code runs on PHP 5 is an illusion
anyway.
No, it's not. What are you talking about? We've been happily using PHP4
with OOP for years. That's basic OO like encapsulating data and
inheritance to extend behaviour. Nothing of that "fancy" exception/PPP
type of OO, just the OO which really helps us ;-)
And the code does work with PHP5.
Please stop the FUD,
- Chris
Hi,
At first $ref =& $this; produced fatal error because of the bug (not by
design).
For example $ref->prop =& $this; worked and works without errors.
So my patch shouldn't be reverted in any case.
At second disallowing such assignments and passign $this by reference will
breake a lot of PHP4 code (Mamaba CMS).
In PHP4 passing $object by refernce and by value had completely different
semantic.
I don't see any reason to disallow 100% proper code (like the the
following).
class Child {
function Child($parent) {
$parent->children[] =& $this;
}
}
Of course using "=& $this" user can breake $this value, but other languages
(C++) allows this too.
I don't think we should be paranoiacs.
Thanks. Dmitry.
-----Original Message-----
From: Derick Rethans [mailto:derick@php.net]
Sent: Monday, October 03, 2005 5:09 PM
To: PHP Developers Mailing List
Subject: [PHP-DEV] $ref =& $this;Hello,
Dmitry committed a fix earlier to ignore the & in the
statement above. I
think this is not a good thing to do as it's simply
conceptually wrong.
The first thing is that ignoring syntax without issuing a warning is
dubious because people might think it does actually work, and
secondly
because I think that the code above is wrong anyway - somewhat in the
same way that "$this = new foo();" is wrong.There is never any need to assign $this by reference, nor to
pass it by
reference to a function as it's an object anyway, making the
references
pointless - I would even go as far as disallowing passing $this by
references to a function - where the reference has to be
ignored again,
otherwise it allows you to chantge $this to a different object with:class Foo {
function byRef(&$f) {
$f = new Bar();
}function modifyThis() {
$this->byRef($this);
}
}I think we should prevent people from writing syntax like
this, as it is
not obvious what is going to happen. This means that we should revert
Dmitry's patch.regards,
Derick--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
Hello Dmitry,
that IS NOT proper code and it wasn't in php 4 either, it was only a
workaround that is no longer needed. Had the php 4 design been correct in
the first place that wouldn't have been allowed in 4 either. Since BC is not
working out anyway i see absolutley no reason to encourage people to
continue to missuse php.
marcus
Monday, October 3, 2005, 4:05:56 PM, you wrote:
Hi,
At first $ref =& $this; produced fatal error because of the bug (not by
design).
For example $ref->prop =& $this; worked and works without errors.
So my patch shouldn't be reverted in any case.
At second disallowing such assignments and passign $this by reference will
breake a lot of PHP4 code (Mamaba CMS).
In PHP4 passing $object by refernce and by value had completely different
semantic.
I don't see any reason to disallow 100% proper code (like the the
following).
class Child {
function Child($parent) {
$parent->children[] =& $this;
}
}
Of course using "=& $this" user can breake $this value, but other languages
(C++) allows this too.
I don't think we should be paranoiacs.
Thanks. Dmitry.
-----Original Message-----
From: Derick Rethans [mailto:derick@php.net]
Sent: Monday, October 03, 2005 5:09 PM
To: PHP Developers Mailing List
Subject: [PHP-DEV] $ref =& $this;Hello,
Dmitry committed a fix earlier to ignore the & in the
statement above. I
think this is not a good thing to do as it's simply
conceptually wrong.
The first thing is that ignoring syntax without issuing a warning is
dubious because people might think it does actually work, and
secondly
because I think that the code above is wrong anyway - somewhat in the
same way that "$this = new foo();" is wrong.There is never any need to assign $this by reference, nor to
pass it by
reference to a function as it's an object anyway, making the
references
pointless - I would even go as far as disallowing passing $this by
references to a function - where the reference has to be
ignored again,
otherwise it allows you to chantge $this to a different object with:class Foo {
function byRef(&$f) {
$f = new Bar();
}function modifyThis() { $this->byRef($this); }}
I think we should prevent people from writing syntax like
this, as it is
not obvious what is going to happen. This means that we should revert
Dmitry's patch.regards,
Derick--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org--
Best regards,
Marcus
Hello Dmitry,
that IS NOT proper code and it wasn't in php 4 either, it was only a
workaround that is no longer needed. Had the php 4 design been correct in
the first place that wouldn't have been allowed in 4 either. Since BC is not
working out anyway i see absolutley no reason to encourage people to
continue to missuse php.marcus
The central issue I see in this regards is that up until this point,
people had the option of writing reasonably complex OO code which
worked on both PHP4 and PHP5. With the advent of disallowing =&
$this; you are explicitly forcing people to create PHP5 branches of
their code.
I believe this will also act as a further deterant for hosts to
migrate to PHP5, as there will be an even greater number of off the
shelf PHP applications which are no longer compatable with PHP5.
Regards,
Jason
http://blog.casey-sweat.us/
See my note regarding the fixes we did in the past 1-2 weeks
regarding references. It's a huge BC break, and quite frankly, it's
not the kind of thing that forces you not to write good code because
it's supported.
Andi
At 07:13 AM 10/3/2005, Marcus Boerger wrote:
Hello Dmitry,
that IS NOT proper code and it wasn't in php 4 either, it was only a
workaround that is no longer needed. Had the php 4 design been correct in
the first place that wouldn't have been allowed in 4 either. Since BC is not
working out anyway i see absolutley no reason to encourage people to
continue to missuse php.marcus
Monday, October 3, 2005, 4:05:56 PM, you wrote:
Hi,
At first $ref =& $this; produced fatal error because of the bug (not by
design).
For example $ref->prop =& $this; worked and works without errors.So my patch shouldn't be reverted in any case.
At second disallowing such assignments and passign $this by reference will
breake a lot of PHP4 code (Mamaba CMS).
In PHP4 passing $object by refernce and by value had completely different
semantic.I don't see any reason to disallow 100% proper code (like the the
following).class Child {
function Child($parent) {
$parent->children[] =& $this;
}
}Of course using "=& $this" user can breake $this value, but other languages
(C++) allows this too.
I don't think we should be paranoiacs.Thanks. Dmitry.
-----Original Message-----
From: Derick Rethans [mailto:derick@php.net]
Sent: Monday, October 03, 2005 5:09 PM
To: PHP Developers Mailing List
Subject: [PHP-DEV] $ref =& $this;Hello,
Dmitry committed a fix earlier to ignore the & in the
statement above. I
think this is not a good thing to do as it's simply
conceptually wrong.
The first thing is that ignoring syntax without issuing a warning is
dubious because people might think it does actually work, and
secondly
because I think that the code above is wrong anyway - somewhat in the
same way that "$this = new foo();" is wrong.There is never any need to assign $this by reference, nor to
pass it by
reference to a function as it's an object anyway, making the
references
pointless - I would even go as far as disallowing passing $this by
references to a function - where the reference has to be
ignored again,
otherwise it allows you to chantge $this to a different object with:class Foo {
function byRef(&$f) {
$f = new Bar();
}function modifyThis() { $this->byRef($this); }}
I think we should prevent people from writing syntax like
this, as it is
not obvious what is going to happen. This means that we should revert
Dmitry's patch.regards,
Derick--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org--
Best regards,
Marcus--
Zend/PHP Conference & Expo
Power Your Business with PHP
October 18-21, 2005 - San Francisco
http://zend.kbconferences.com/
Assigning to it will break "this" in the symbol table, or EG(This)?
If it's the latter then it is a problem (and it's the reason I didn't
support it to begin with).
Andi
At 07:05 AM 10/3/2005, Dmitry Stogov wrote:
Hi,
At first $ref =& $this; produced fatal error because of the bug (not by
design).
For example $ref->prop =& $this; worked and works without errors.So my patch shouldn't be reverted in any case.
At second disallowing such assignments and passign $this by reference will
breake a lot of PHP4 code (Mamaba CMS).
In PHP4 passing $object by refernce and by value had completely different
semantic.I don't see any reason to disallow 100% proper code (like the the
following).class Child {
function Child($parent) {
$parent->children[] =& $this;
}
}Of course using "=& $this" user can breake $this value, but other languages
(C++) allows this too.
I don't think we should be paranoiacs.Thanks. Dmitry.
-----Original Message-----
From: Derick Rethans [mailto:derick@php.net]
Sent: Monday, October 03, 2005 5:09 PM
To: PHP Developers Mailing List
Subject: [PHP-DEV] $ref =& $this;Hello,
Dmitry committed a fix earlier to ignore the & in the
statement above. I
think this is not a good thing to do as it's simply
conceptually wrong.
The first thing is that ignoring syntax without issuing a warning is
dubious because people might think it does actually work, and
secondly
because I think that the code above is wrong anyway - somewhat in the
same way that "$this = new foo();" is wrong.There is never any need to assign $this by reference, nor to
pass it by
reference to a function as it's an object anyway, making the
references
pointless - I would even go as far as disallowing passing $this by
references to a function - where the reference has to be
ignored again,
otherwise it allows you to chantge $this to a different object with:class Foo {
function byRef(&$f) {
$f = new Bar();
}function modifyThis() { $this->byRef($this); }}
I think we should prevent people from writing syntax like
this, as it is
not obvious what is going to happen. This means that we should revert
Dmitry's patch.regards,
Derick--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org--
--
Zend/PHP Conference & Expo
Power Your Business with PHP
October 18-21, 2005 - San Francisco
http://zend.kbconferences.com/
Andi Gutmans wrote:
Assigning to it will break "this" in the symbol table, or EG(This)? If
it's the latter then it is a problem (and it's the reason I didn't
support it to begin with).
Given that:
class foo {
function bar() {
$this->a = 1;
$ref = &$this;
$ref->b = 2;
$ref = null;
}
}
$x = new foo;
$x->bar();
echo $x->a, $x->b;
Outputs 12 and doesn't appear to cause any major badness internally, I
don't really see any reason to disallow it. If an E_STRICT could be
raised without affecting performance too much that would be good since
it is a useless assignment. Given the lack of badness on the php5 side
and the high level of goodness for php4 portability, I say leave it as
it is now.
-Rasmus
Yep, I agree with this. We'll check but I'm pretty sure we're not
corrupting EG(This) (which in any case is an implementation detail
and too relevant to this discussion).
As in PHP, you can't change the $this pointer, I do think we should
have a message about this. I'd suggest an E_WARNING because it's for
the same reason as over writing $this that you'd want to take a
reference, you shouldn't really do it. We can also mention in the
warning that this support will be deprecated in future versions...
Andi
At 08:11 AM 10/3/2005, Rasmus Lerdorf wrote:
Andi Gutmans wrote:
Assigning to it will break "this" in the symbol table, or EG(This)? If
it's the latter then it is a problem (and it's the reason I didn't
support it to begin with).Given that:
class foo {
function bar() {
$this->a = 1;
$ref = &$this;
$ref->b = 2;
$ref = null;
}
}
$x = new foo;
$x->bar();
echo $x->a, $x->b;Outputs 12 and doesn't appear to cause any major badness internally, I
don't really see any reason to disallow it. If anE_STRICTcould be
raised without affecting performance too much that would be good since
it is a useless assignment. Given the lack of badness on the php5 side
and the high level of goodness for php4 portability, I say leave it as
it is now.-Rasmus
Zend/PHP Conference & Expo
Power Your Business with PHP
October 18-21, 2005 - San Francisco
http://zend.kbconferences.com/
Hey,
I was the original person that started disallowing assigning $this by
reference.
Question really boils down to, how is this different from the
reference fixes we did a couple of weeks ago, where due to too many
apps breaking (and a lot broke) we created a work-around for this
behavior with a warning.
I think this case is pretty much identical, so we should probably
treat it as such and escalate to error in 6.0.
And
At 06:09 AM 10/3/2005, Derick Rethans wrote:
Hello,
Dmitry committed a fix earlier to ignore the & in the statement above. I
think this is not a good thing to do as it's simply conceptually wrong.
The first thing is that ignoring syntax without issuing a warning is
dubious because people might think it does actually work, and secondly
because I think that the code above is wrong anyway - somewhat in the
same way that "$this = new foo();" is wrong.There is never any need to assign $this by reference, nor to pass it by
reference to a function as it's an object anyway, making the references
pointless - I would even go as far as disallowing passing $this by
references to a function - where the reference has to be ignored again,
otherwise it allows you to chantge $this to a different object with:class Foo {
function byRef(&$f) {
$f = new Bar();
}function modifyThis() { $this->byRef($this); }}
I think we should prevent people from writing syntax like this, as it is
not obvious what is going to happen. This means that we should revert
Dmitry's patch.regards,
Derick--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org--
Zend/PHP Conference & Expo
Power Your Business with PHP
October 18-21, 2005 - San Francisco
http://zend.kbconferences.com/