19 years ago by Derick Rethans — view source

unread

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

19 years ago by Marcus Boerger — view source

unread

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

19 years ago by Richard Mann — view source

unread

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.

19 years ago by Derick Rethans — view source

unread

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

19 years ago by Robert Cummings — view source

unread

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. |
`------------------------------------------------------------'

19 years ago by Robert Cummings — view source

unread

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.

19 years ago by Pierre — view source

unread

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

19 years ago by Christian Schneider — view source

unread

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

19 years ago by Marcus Boerger — view source

unread

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

19 years ago by Christian Schneider — view source

unread

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

19 years ago by Marcus Boerger — view source

unread

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 an E_STRICT plus 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

19 years ago by Christian Schneider — view source

unread

Marcus Boerger wrote:

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.

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

19 years ago by Marcus Boerger — view source

unread

Hello Christian,

Tuesday, October 4, 2005, 10:14:05 AM, you wrote:

Marcus Boerger wrote:

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.

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

19 years ago by Derick Rethans — view source

unread

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?

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

19 years ago by Marcus Boerger — view source

unread

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 elegant

But 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

19 years ago by Michael Wallner — view source

unread

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

19 years ago by Christian Schneider — view source

unread

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

19 years ago by Dmitry Stogov — view source

unread

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

19 years ago by Marcus Boerger — view source

unread

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

19 years ago by Jason Sweat — view source

unread

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/

19 years ago by Andi Gutmans — view source

unread

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/

19 years ago by Andi Gutmans — view source

unread

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/

19 years ago by Rasmus Lerdorf — view source

unread

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

19 years ago by Andi Gutmans — view source

unread

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

Zend/PHP Conference & Expo
Power Your Business with PHP
October 18-21, 2005 - San Francisco
http://zend.kbconferences.com/

19 years ago by Andi Gutmans — view source

unread

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/

19 years ago by Christian Schneider — view source

unread

Jani Taskinen wrote:

Yes, but OO in PHP 4 is illusion.

Ok, I see, I replied to a troll. Silly of me. Won't happen again after
this one, I promise.

Nobody's bashing you for using PHP. Just for using PHP 4. :)

Are you reading my posts? Oh no, I forgot, you're just trolling.

Over and out,

Chris

19 years ago by Derick Rethans — view source

unread

Jani Taskinen wrote:
Yes, but OO in PHP 4 is illusion.
Ok, I see, I replied to a troll. Silly of me. Won't happen again after this
one, I promise.

Atleast he contributes something useful to the PHP project too.

regards,
Derick

--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

19 years ago by Edin Kadribasic — view source

unread

Derick Rethans wrote:

Jani Taskinen wrote:

Yes, but OO in PHP 4 is illusion.

Ok, I see, I replied to a troll. Silly of me. Won't happen again after this
one, I promise.

Atleast he contributes something useful to the PHP project too.

I'd wish that some of the PHP contributors would post more helpful
comments about the project than calling it a 'nazi project', everything
they don't like (such as PDO) 'crap'. Also trying to shoot down
everything that is not in the cool branch of the day (5.1 these days).

No wonder that nothing productive can come out of such 'contributions'
on this list.

Now, why don't we focus on what's important and get 5.1 released.

Zeev, Andi if you don't have time for doing Release Mastering (and it
seems that you don't) should we assign someone else for the task. Ilia
said that would do it, and he did a great job with RM in the past.

Edin

19 years ago by Andi Gutmans — view source

unread

Guys,

It's really not about who is RM. The main reason why PHP 5.1 has been
delayed so much is because every time we were about to release,
another critical problem creeped up. We had PDO problems, class
constants, reference issues, date issues, security issues, and others
(more or less in that order). So releasing a PHP 5.1 was just not
possible, and even now, we definitely have to go through an
additional release candidate. I have no problem with Ilia picking up
and running the release (especially with all the Jewish holidays
coming up), but be aware that this wasn't the main issue from my
point of view. And if you look chronologically at the events, you'll
see that there really wasn't a point in time to release something
stable. As much as I personally wanted PHP 5.1 to be out the door
already, it doesn't make much sense to release it when the CVS is not
stable. So I'm glad Ilia has offered to give this one a push, but we
still need to release another RC and be sure we're doing well.

Regarding BC breakage. I'm not saying we shouldn't break BC in some
cases, but in many cases, there's no big advantage (except for some
people's warm and fuzzy feelings), and it can cause a lot of heart
aches and disruption in PHP use. Migration is very important.
Microsoft is loosing quite a bit of their users because they created
a serious disruption in going from ASP to ASP.NET. Making that move
hard, makes people reconsider their use of technology which at this
point includes JSP, .NET, Ruby on Rails and Python. I think we have
to be responsible to try and prevent that and make the move easy.
Mixing the hosting providers into it, which a huge amount of the PHP
community is using, including software like Gallery, Mambo, various
forums, etc. it will be even more devastating to PHP use if we create
too many disruptions.
Now some disruptions have to happen but it has to be a balanced
decision and not just an idealists decision; especially when
supporting BC is not such a huge maintenance headache which in many
cases is true, and just recently Dmitry showed it can be quite
possible without impacting the PHP 5 features.

We are also creating far too many disruptions between versions
without giving info to our users. I already mentioned in a smaller
forum that we need an UPGRADING file where we explain what
disruptions we have and how to upgrade (I want this to be in PHP 5.1
and we've already started working on some but holidays... I'd
appreciate help). We should make sure that as we post releases we
provide info and only way to do this is to do it as part of the dev
cycle and not have the RM try and remember what upgrading notes we
need). Also, responding to things like the reference break is
important (thanks to Dmitry that issue is very much improved), and
hopefully with 4.4.1 and 5.0.6 with some release announcement coupled
with the UPGRADING file (side-by-side with NEWS) we'd fix this problem.

Regarding Unicode. We discussed this many times and agreed to support
both for PHP 6. Performance quite a major issue with Unicode, and so
is keeping BC to allow for an easy upgrade. I wouldn't take
performance lightly. I do think that there's a chance that when PHP 6
rolls out, and if the Unicode prooves itself and the masses migrate
to that, that it might make sense to re-evaluate and see if it makes
sense to cut the old support out. But at this point in time, it's far
too premature to come to this conclusion. Most people here haven't
even run it and checked it. Again, this should be done with a
balanced view and not just making idealist decisions.

I hope people take some of these things to heart, because I think we
have a responsibility to the large community out there to take a
balanced view. PHP 5 and PHP 5.1 are huge steps forward and are
providing an impressive array of features, so I wouldn't say we're
not making progress despite the fact that we've tried to keep BC when
feasible (and with the important stuff we haven't). Remember, when
you're part of a project, things always look grimmer because you see
the insides. It's true for companies and true for open-source.

Sorry for the long email. It's just that I have to jump on a plane
tomorrow and will barely be available for the next 2-3 days.

Andi

At 02:43 AM 10/4/2005, Edin Kadribasic wrote:

Derick Rethans wrote:

Jani Taskinen wrote:

Yes, but OO in PHP 4 is illusion.

Ok, I see, I replied to a troll. Silly of me. Won't happen again after this
one, I promise.

Atleast he contributes something useful to the PHP project too.

I'd wish that some of the PHP contributors would post more helpful
comments about the project than calling it a 'nazi project', everything
they don't like (such as PDO) 'crap'. Also trying to shoot down
everything that is not in the cool branch of the day (5.1 these days).

No wonder that nothing productive can come out of such 'contributions'
on this list.

Now, why don't we focus on what's important and get 5.1 released.

Zeev, Andi if you don't have time for doing Release Mastering (and it
seems that you don't) should we assign someone else for the task. Ilia
said that would do it, and he did a great job with RM in the past.

Edin

Zend/PHP Conference & Expo
Power Your Business with PHP
October 18-21, 2005 - San Francisco
http://zend.kbconferences.com/

19 years ago by Steph — view source

unread

We are also creating far too many disruptions between versions
without giving info to our users. I already mentioned in a smaller
forum that we need an UPGRADING file where we explain what
disruptions we have and how to upgrade (I want this to be in PHP 5.1
and we've already started working on some but holidays... I'd
appreciate help).

I agree, and I'd be more than happy to work on that. Can you commit what
you have?

Steph

19 years ago by Rasmus Lerdorf — view source

unread

Andi Gutmans wrote:

Regarding BC breakage. I'm not saying we shouldn't break BC in some
cases, but in many cases, there's no big advantage (except for some
people's warm and fuzzy feelings), and it can cause a lot of heart aches
and disruption in PHP use.

It's always a tricky balance and I agree with Andi and Dmitry on this
particular one. There are plenty of places where a BC break might be
warranted, but we really have to pick our spots very carefully,
communicate the change and provide clear and simple examples showing
people how their code should be fixed. The number of times we can do
this is limited and the number of areas we can touch is limited.

People seem to have latched onto this $ref =& $this issue for some
reason. Is this really a place where you want to use up some of our BC
breaking karma points? I really don't see this particular point as
being much of a problem. It's somewhat dangerous code in PHP5, but
certainly not illegal in itself. And while much PHP 4 OOP code will
need to be fixed to run in PHP 5 that is a different issue from the
ability to write OOP code that has a chance of working in both. For
dangerous, but technically legal code, throwing a warning seems like the
best option to me.

So, let's pick our battles in a sane and organized manner and give
people a feasible migration path.

-Rasmus

19 years ago by Lukas Smith — view source

unread

Rasmus Lerdorf wrote:

People seem to have latched onto this $ref =& $this issue for some
reason. Is this really a place where you want to use up some of our BC
breaking karma points? I really don't see this particular point as

Atleast for me it was more a general rant ..

regards,
Lukas

$ref =& $this;

Cheers, Rob.

Cheers, Rob.

Regards,

Cheers,
Rob.

Cheers,
Rob.