Everything

php

Home » Project » Newsgroups » php.internals » $ref =& $this; »

$ref =& $this;

php.internals

Derick Rethans

20 years ago

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

Marcus Börger

20 years ago

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

20 years ago

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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php

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

Derick Rethans

20 years ago

On Mon, 3 Oct 2005, Richard Mann wrote:

> 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

Robert Cummings

20 years ago

On Mon, 2005-10-03 at 09:49, Derick Rethans wrote:

> On Mon, 3 Oct 2005, Richard Mann wrote:
>
> > 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.          |
`------------------------------------------------------------'

Robert Cummings

20 years ago

On Mon, 2005-10-03 at 10:40, Robert Cummings wrote:

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

Pierre Joye

20 years ago

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

Christian Schneider

20 years ago

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

Marcus Börger

20 years ago

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

Christian Schneider

20 years ago

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

Marcus Börger

20 years ago

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

Christian Schneider

20 years ago

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

Marcus Börger

20 years ago

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

Derick Rethans

20 years ago

On Mon, 3 Oct 2005, Christian Schneider 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.

Derick

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

Marcus Börger

20 years ago

Hello Derick,

Tuesday, October 4, 2005, 9:41:39 AM, you wrote:

> On Mon, 3 Oct 2005, Christian Schneider 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

Michael Wallner

20 years ago

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 >

Christian Schneider

20 years ago

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

Jani Taskinen

20 years ago

On Tue, 4 Oct 2005, Christian Schneider wrote:

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

il·lu·sion:
1. An erroneous perception of reality.
2. An erroneous concept or belief.
3. The condition of being deceived by a false perception or belief.
4. Something, such as a fantastic plan or desire, that causes an erroneous belief or perception.

--Jani

--
Give me your money at @ <http://pecl.php.net/wishlist.php/sniper>
Donating money may make me happier and friendlier for a limited period!
Death to all 4 letter abbreviations starting with P!

Christian Schneider

20 years ago

Jani Taskinen wrote:

> On Tue, 4 Oct 2005, Christian Schneider wrote:
>> And the code _does_ work with PHP5.
>
>     il·lu·sion:
>     1. An erroneous perception of reality.
>     2. An erroneous concept or belief.
>     3. The condition of being deceived by a false perception or belief.
>     4. Something, such as a fantastic plan or desire, that causes an
> erroneous belief or perception.

Just to clarify: I never said _all_ PHP4 OO code works with PHP5. But
_our_ code does. Nothing illusionary about that.

Please stop bashing me for using PHP to earn my living ;-)
- Chris

Jani Taskinen

20 years ago

On Tue, 4 Oct 2005, Christian Schneider wrote:

>
> Jani Taskinen wrote:
>> On Tue, 4 Oct 2005, Christian Schneider wrote:
>>> And the code _does_ work with PHP5.
>>
>>     il·lu·sion:
>>     1. An erroneous perception of reality.
>>     2. An erroneous concept or belief.
>>     3. The condition of being deceived by a false perception or belief.
>>     4. Something, such as a fantastic plan or desire, that causes an
>> erroneous belief or perception.
>
> Just to clarify: I never said _all_ PHP4 OO code works with PHP5. But _our_
> code does. Nothing illusionary about that.

Yes, but OO in PHP 4 is illusion.

> Please stop bashing me for using PHP to earn my living ;-)

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

--Jani

--
Give me your money at @ <http://pecl.php.net/wishlist.php/sniper>
Donating money may make me happier and friendlier for a limited period!
Death to all 4 letter abbreviations starting with P!

Christian Schneider

20 years ago

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

Derick Rethans

20 years ago

On Tue, 4 Oct 2005, Christian Schneider 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.

regards,
Derick

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

Edin Kadribasic

20 years ago

Derick Rethans wrote:

> On Tue, 4 Oct 2005, Christian Schneider 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

Dmitry Stogov

20 years ago

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.

Marcus Börger

20 years ago

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
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>

Best regards,
Marcus

Jason Sweat

20 years ago

On 10/3/05, Marcus Boerger <helly@php.net> 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

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/

Dmitry Stogov

20 years ago

Marcus,

BC is working. PHP5 has zend.ze1_compatibility_mode and some PHP
applications use it.

BTW to disallow =& $this and passing $this by reference we should change not
only compiler but also executor.
On each parameter passing we should check if we do passing $this by
reference (it is not possile to eleminaty all such checks at compile time).

Dmitry.

Andi Gutmans

20 years ago

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
> >>
> >> --
> >> PHP Internals - PHP Runtime Development Mailing List
> >> To unsubscribe, visit: http://www.php.net/unsub.php
> >>
> >>
>
>
>
>
>Best regards,
>  Marcus
>
>--
>PHP Internals - PHP Runtime Development Mailing List
>To unsubscribe, visit: http://www.php.net/unsub.php

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

Andi Gutmans

20 years ago

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
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
>--
>PHP Internals - PHP Runtime Development Mailing List
>To unsubscribe, visit: http://www.php.net/unsub.php

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

Rasmus Lerdorf

20 years ago

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

Andi Gutmans

20 years ago

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/

Derick Rethans

20 years ago

On Mon, 3 Oct 2005, Dmitry Stogov wrote:

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

Yes I know. In PHP 4 the OO was totally crap, and now you're saying you
want to keep "bogus" behavior for eternity so that all the PHP 4 apps
can still run?

I am quite getting tired of having to maintain BC for *every* little
stupid thing we ever did. I think it's time to start with a clean slate
as it's all getting way to annoying to maintain (and know what subtle
differences there are between PHP versions).

The same thing we now see with the unicode support in PHP 6 where we
choose for maintaining BC with older PHP versions in every way possible.
Now we get code like this:

if (Z_TYPE_PP(str) == IS_UNICODE) {
php_u_trim(Z_USTRVAL_PP(str), Z_USTRLEN_PP(str), Z_USTRVAL_PP(what), Z_USTRLEN_PP(what), return_value, mode TSRMLS_CC);
} else {
php_trim(Z_STRVAL_PP(str), Z_STRLEN_PP(str), Z_STRVAL_PP(what), Z_STRLEN_PP(what), Z_TYPE_PP(str), return_value, mode TSRMLS_CC);
}

Which is in my opinion totally unmaintainable in the long run. I really
think we would be much better of to get rid of IS_STRING and only have
IS_BINARY and IS_UNICODE - do it the nice and clean way and forget about
BC. We would definitely see the benefits in the long run.

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

So if C++ allows this we should too? I think that's one invalid reason.
There is no point of assigning by reference here, so we shouldn't allow
that. That way our users see "oh, I did something wrong, let's fix it" -
and yes, it will break BC. But the OO model in PHP 5 is totally
different than in PHP 4, so I see no problems with that.

regards,
Derick

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

Marcus Börger

20 years ago

Hello Derick,

Tuesday, October 4, 2005, 9:49:00 AM, you wrote:

> On Mon, 3 Oct 2005, Dmitry Stogov wrote:

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

> Yes I know. In PHP 4 the OO was totally crap, and now you're saying you
> want to keep "bogus" behavior for eternity so that all the PHP 4 apps
> can still run?

No. And it is even worse. We start maintaining BC for things we always
agreed we do not support - just because some crazy app used this for a
workaround of a problem they couldn't solve? Maybe they should have asked
for the fature - but the answer would have been we don't support that....

> I am quite getting tired of having to maintain BC for *every* little
> stupid thing we ever did. I think it's time to start with a clean slate
> as it's all getting way to annoying to maintain (and know what subtle
> differences there are between PHP versions).

> The same thing we now see with the unicode support in PHP 6 where we
> choose for maintaining BC with older PHP versions in every way possible.
> Now we get code like this:

>         if (Z_TYPE_PP(str) == IS_UNICODE) {
>             php_u_trim(Z_USTRVAL_PP(str), Z_USTRLEN_PP(str),
> Z_USTRVAL_PP(what), Z_USTRLEN_PP(what), return_value, mode TSRMLS_CC);
>         } else {
>             php_trim(Z_STRVAL_PP(str), Z_STRLEN_PP(str),
> Z_STRVAL_PP(what), Z_STRLEN_PP(what), Z_TYPE_PP(str), return_value, mode TSRMLS_CC);
>         }

> Which is in my opinion totally unmaintainable in the long run. I really
> think we would be much better of to get rid of IS_STRING and only have
> IS_BINARY and IS_UNICODE - do it the nice and clean way and forget about
> BC. We would definitely see the benefits in the long run.

That's what i said directly when first looking at the current unicode
implementation. It is absolute unmaintainable for any non full time php-c
code developer. We have tons of "_u_" function name inlays and thousands of
macros and i am quite sure none of that is necessary. And for instance right
no i still have absolutley no idea of what is going on. And by looking at
the hundreds of warnings - well other don't do either - not even in the
engine code. And don't tell me "warnings". Yesturday i fixed at least one
that was a real error and seeing hundres of warnigns in our code makes me
blind - It makes me ignore the help the compiler could give me. And believe
me i write warning free code for a reason.

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

A reference in C++ is a very different thing. And especially it doesn't allow
you to fuck up any instance or cause memory corruption or invalid variables.
If you don't understand c++ don't use it here.

> So if C++ allows this we should too? I think that's one invalid reason.
> There is no point of assigning by reference here, so we shouldn't allow
> that. That way our users see "oh, I did something wrong, let's fix it" -
> and yes, it will break BC. But the OO model in PHP 5 is totally
> different than in PHP 4, so I see no problems with that.

And right now before 5.1 comes out we still have the choice. If i consider
all the arguments i have heared then only a handfull of people must be using
php 5 right now and there mostly for testing or for running php 4 code maybe
a little bit adapter, like changing var public.


Best regards,
Marcus

Dmitry Stogov

20 years ago

Marcus, Derick,

$var = & $this is proper code, however changing $var after such assignment
right in this methid can cause mesh. Only this method will be affected. Look
into example:

<?php
class foo {
function foo() {
$x =& $this;
$x = null;
var_dump($this);
$this->x = 2;
}
}

$x = new foo();
var_dump($x);
?>

The code above doesn't destroy object and doesn't change EG(This). It
changes only $this in active symbol table. This can cause some mesh, but
shouldn't crash PHP.

So $x = &$this is proper but dangerous code.
I think we can make E_STRICT warning for it, but we cannot disallow it.

see follow...

> -----Original Message-----
> From: Marcus Boerger [mailto:helly@php.net]
> Sent: Tuesday, October 04, 2005 12:03 PM
> To: Derick Rethans
> Cc: Dmitry Stogov; 'PHP Developers Mailing List'
> Subject: Re: [PHP-DEV] $ref =& $this;
>
>
> Hello Derick,
>
> Tuesday, October 4, 2005, 9:49:00 AM, you wrote:
>
> > On Mon, 3 Oct 2005, Dmitry Stogov wrote:
>
> >> 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.
>
> > Yes I know. In PHP 4 the OO was totally crap, and now you're saying
> > you
> > want to keep "bogus" behavior for eternity so that all the
> PHP 4 apps
> > can still run?
>
> No. And it is even worse. We start maintaining BC for things
> we always agreed we do not support - just because some crazy
> app used this for a workaround of a problem they couldn't
> solve? Maybe they should have asked for the fature - but the
> answer would have been we don't support that....

I agree on removing some stupid things from PHP (break $var).
But this not the case.

> > I am quite getting tired of having to maintain BC for *every* little
> > stupid thing we ever did. I think it's time to start with a
> clean slate
> > as it's all getting way to annoying to maintain (and know
> what subtle
> > differences there are between PHP versions).
>
> > The same thing we now see with the unicode support in PHP 6 where we
> > choose for maintaining BC with older PHP versions in every
> way possible.
> > Now we get code like this:
>
> >         if (Z_TYPE_PP(str) == IS_UNICODE) {
> >             php_u_trim(Z_USTRVAL_PP(str), Z_USTRLEN_PP(str),
> > Z_USTRVAL_PP(what), Z_USTRLEN_PP(what), return_value, mode
> TSRMLS_CC);
> >         } else {
> >             php_trim(Z_STRVAL_PP(str), Z_STRLEN_PP(str),
> > Z_STRVAL_PP(what), Z_STRLEN_PP(what), Z_TYPE_PP(str),
> return_value, mode TSRMLS_CC);
> >         }
>
> > Which is in my opinion totally unmaintainable in the long run. I
> > really
> > think we would be much better of to get rid of IS_STRING
> and only have
> > IS_BINARY and IS_UNICODE - do it the nice and clean way and
> forget about
> > BC. We would definitely see the benefits in the long run.
>
> That's what i said directly when first looking at the current
> unicode implementation. It is absolute unmaintainable for any
> non full time php-c code developer. We have tons of "_u_"
> function name inlays and thousands of macros and i am quite
> sure none of that is necessary.

I agree about unicode support implementation.
I did a lot of work on it, but I don't like it.

Dmitry.

Marcus Börger

20 years ago

Hello Dmitry,

Tuesday, October 4, 2005, 11:16:36 AM, you wrote:

> Marcus, Derick,

> $var = & $this is proper code, however changing $var after such assignment
> right in this methid can cause mesh. Only this method will be affected. Look
> into example:

Which straw are you now reaching for? The one that does allow you to use
risky/vulnerable code unless you actively use the vulnerability?

Oliver Grätz

20 years ago

Marcus Boerger schrieb:

> No. And it is even worse. We start maintaining BC for things we always
> agreed we do not support

This gave me a very silly idea (or not?):
Release a PHP 4.9 version or something like that!

And here's what it looks like: It is a complete PHP 5.1 in disguise plus
a parallel installtion of the latest true PHP 4 branch. The 5.1 code is
active by default and people are forced to switch to the other codebase
by activating a compatibility switch which is called

crappy_old_code_you_should_not_use_compatibility = on

This way a lot of people will finally get a PHP5 on their machine since
a lot of hosters don't switch to PHP5 but they keep their PHP4
installation on the latest release. The name of the switch in
combination with the 9 in the release number will finally make clear to
people that they should better fix stuff instead of sticking to old
versions _and_ that there probably won't be any new PHP4 versions.

AllOLLi

Bart van Bragt

20 years ago

Derick Rethans wrote:

> I am quite getting tired of having to maintain BC for *every* little
> stupid thing we ever did. I think it's time to start with a clean slate
> as it's all getting way to annoying to maintain (and know what subtle
> differences there are between PHP versions).

How do you think that we (the PHP coders) feel? We need to have the
weirdest workarounds in our code to get it to run on all those different
PHP version out there that have those subtle differences. We can't use
PHP5 features even if we wanted to because just a few percent of the
hosts out there have deployed PHP5 (for obvious reasons).

Starting with a clean slate would cool for you (it would enable you to
do new and cool things) but it would either force us to switch to a more
stable language or keep two completely different codebases. I know what
I would choose.

There are some whacky things in PHP4 and PHP5 that need to be fixed and
to fix that BC sometimes breaks. No problem with that. The problem is
that you're breaking BC again while almost no-one has switched to PHP5
yet because of the BC breaks between 4.x and 5.0. Breaking BC again is
certainly not going to help the adoption of PHP5. Please just accept
that things can't move at the speed that you'd like. It takes ages
before people upgrade, that's just the way it is. Breaking BC won't
force people to upgrade, it will keep them from upgrading.

With kind regards,

Bart van Bragt

Lukas Smith

20 years ago

Bart van Bragt wrote:

> There are some whacky things in PHP4 and PHP5 that need to be fixed and
> to fix that BC sometimes breaks. No problem with that. The problem is
> that you're breaking BC again while almost no-one has switched to PHP5
> yet because of the BC breaks between 4.x and 5.0. Breaking BC again is
> certainly not going to help the adoption of PHP5. Please just accept
> that things can't move at the speed that you'd like. It takes ages
> before people upgrade, that's just the way it is. Breaking BC won't
> force people to upgrade, it will keep them from upgrading.

I think the problem is that constantly breaking a bit of BC is worse
than breaking BC once a bit more severly. To me the main principle of
PHP was ease of use. However alot of wacky things have resulted in
reducing the number of people that can truely understand any PHP code to
a very small elite. So unless we shed ourselves of the past at some
point we are in danger of killing off one of the key advantages of PHP.

Of course there is an inherite danger in taking this step. Will the
userbase migrate to that new PHP version or will they jump ship towards
Ruby on Rails and friends? It hard to tell, but if we make sure that
this new language can compete with the other languages on the block
(already existing or emerging) we shouldn't be worried about that
future. Actually not taking this step might result in a situation where
we will eventually find ourselves more and more wasting time on past
mistakes. I doubt this will be good for any of us in the long run. While
I doubt we will see alot of core people moving to other languages we
will some day wake up to find little influx of new people who are
willing to join this "mess". This will in turn kill off another key
advantage of PHP which was the quick adoption of new possibilities and
the rapid expansion of possibilities.

I think that eZ is an example of a company that shows its willing to
take a risk in betting their money on PHP6 only, because they are
producing a product that will then simply be on a cleaner basis for its
customers. Other companies in much more controlled environments would be
able to take a step like this much more easily. I know I would much more
happily embrace a cleaned up PHP6 compared to a somewhat BC PHP5.

regards,
Lukas

Gareth Ardron

20 years ago

Lukas Smith wrote:

> I think that eZ is an example of a company that shows its willing to
> take a risk in betting their money on PHP6 only, because they are
> producing a product that will then simply be on a cleaner basis for
> its customers. Other companies in much more controlled environments
> would be able to take a step like this much more easily. I know I
> would much more happily embrace a cleaned up PHP6 compared to a
> somewhat BC PHP5.

fwiw, I'd second that. 5 & 5.1 do put out a lot of warnings and notices
about bad coding style which were accepted in php4. It'd make sense to
go down this route and say "ok, this is a major version release. Lots of
stuff will need to be re-tested to make sure it all works properly".

Of course, the key thing here would be making sure that you could run
php4.x/5.x alongside a php6 install so that people can easily test
things without risk of breaking existing apps still on the same server.

Derick Rethans

20 years ago

On Tue, 4 Oct 2005, Gareth Ardron wrote:

> Of course, the key thing here would be making sure that you could run
> php4.x/5.x alongside a php6 install so that people can easily test things
> without risk of breaking existing apps still on the same server.

It's quite easy to set something like that up, but not in the same
apache:
http://ez.no/community/articles/multiple_apache_installations_howto
(Although it talkes about 4.3 and 4.4, it's also applicable for 4.4 and
6.0 f.e.).

Derick

Bart van Bragt

20 years ago

Lukas Smith wrote:

> I think that eZ is an example of a company that shows its willing to
> take a risk in betting their money on PHP6 only, because they are
> producing a product that will then simply be on a cleaner basis for its
> customers. Other companies in much more controlled environments would be
> able to take a step like this much more easily. I know I would much more
> happily embrace a cleaned up PHP6 compared to a somewhat BC PHP5.

Correct, if you are a company and you have some control over the
installed PHP version then the problem isn't that big. But it doesn't
work that way for the open source projects out there and the millions of
people that are using PHP on a shared hosting server. We just recently
decided to drop PHP 4.2 support, doing that sooner would increase the
support load for our project quite a bit. We rather spend that time on
improving the product/project. If you have a (popular/mainstream)
open-source project you have to make sure that your software runs on
just about anything. safe_mode on/off, zend.ze1_compatibility_mode
on/off, version 4.3, 5.1, register_globals, wacky mangling of hostnames,
weird problems with header(), etc, etc. If you don't work around all
those bugs you'll have to answer a LOT of complaints from a lot of users
(that don't have control over their hosting environment).

Again; breaking compatibility is a necessary evil. I really don't mind
when this happens if it is with ample warning and if it makes sense. Not
being allowed to nest some simple array/string functions doesn't make
sense. PHP4 code is going to be around for quite some time, I still run
into users trying to use code that requires register_globals :\ Please
keep in mind that the world out there isn't going to install the latest
and coolest PHP release just because it's cool. Most companies run a PHP
release because it's tried, tested, stable and compatible with what the
customers want to run. I know that sucks, there are quite a few things
that we would like to do different too but we can't because we have to
stay compatible with PHP 4.x. Same with browser support. We could do
really cool stuff if everyone was on Firefox 1.5 but that's just not the
way it is and that's not how it's going to be in the next few years.

Bart

Derick Rethans

20 years ago

On Tue, 4 Oct 2005, Bart van Bragt wrote:

> Lukas Smith wrote:
> > I think that eZ is an example of a company that shows its willing to take a
> > risk in betting their money on PHP6 only, because they are producing a
> > product that will then simply be on a cleaner basis for its customers. Other
> > companies in much more controlled environments would be able to take a step
> > like this much more easily. I know I would much more happily embrace a
> > cleaned up PHP6 compared to a somewhat BC PHP5.
>
> Correct, if you are a company and you have some control over the installed PHP
> version then the problem isn't that big.

Actually, we have no control over this at all. We already need to work
around issues in different PHP version (4.3. vs. 4.4 for example). We're
taking quite a risk to go straight to PHP 6, but we still believe in
that it is going to be a good idea. Especially when we can get rid of
some of the BC ballast that PHP is carrying with it right now.

> If you don't work around all those bugs you'll have to answer a LOT of
> complaints from a lot of users (that don't have control over their
> hosting environment).

Sure, I know everything about that, but those people can also switch
hosts, and which is what some of our users hapily do.

regards,
Derick

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

Derick Rethans

20 years ago

On Tue, 4 Oct 2005, Bart van Bragt wrote:

> Starting with a clean slate would cool for you (it would enable you to do new
> and cool things) but it would either force us to switch to a more stable
> language or keep two completely different codebases. I know what I would
> choose.

But who says your code should run on the new version? You don't *have*
to upgrade per se. It merely allows newly developed projects to run on a
cleaner version of PHP, which would undoubtfully also be faster (because
we wouldn't have any BC ballast).

> There are some whacky things in PHP4 and PHP5 that need to be fixed and to fix
> that BC sometimes breaks. No problem with that. The problem is that you're
> breaking BC again while almost no-one has switched to PHP5 yet because of the
> BC breaks between 4.x and 5.0.

Are you sure it's because it breaks BC? We don't know why people don't
migrate. And for us, we didn't migrate because *we* want to start with a
new clean code base too, and not something hackish that just makes it
work with PHP 5.

> Breaking BC again is certainly not going to help the adoption of PHP5.

It's not going to help people to "migrate their code", that's for sure.
But as I said before, you don't *have* to upgrade.

> Please just accept that things can't move at the speed that you'd
> like. It takes ages before people upgrade, that's just the way it is.
> Breaking BC won't force people to upgrade, it will keep them from
> upgrading.

Yes, but it will also result in PHP being less and less competitive
because we have to maintain all the old (broken) behavior (and make sure
we never change anyting there).

Derick

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

Bart van Bragt

20 years ago

Derick Rethans wrote:

> But who says your code should run on the new version? You don't *have*
> to upgrade per se. It merely allows newly developed projects to run on a
> cleaner version of PHP, which would undoubtfully also be faster (because
> we wouldn't have any BC ballast).

If I have a newly developed application then I can just as well go for
something like RoR or Python or Java if I want something new and crispy
with all the cool new features.

I don't want that, I want something that can be used by almost anyone
with a webserver. I don't care (that much) for the new and cool things.
Sure it's very annoying that it's close to impossible to use (for
instance) UTF8 in PHP but I'd rather be able to run my software just
about anywhere with some restrictions in the language than being able to
use all the new and cool stuff on just a few servers out there or with
just a few clients. Skipping version 5 is just not an option for a LOT
of people out there. Especially all the OS projects (phpBB, phpMyAdmin,
Mambo, Gallery, Wordpress, etc, etc, etc) out there. They _have_ to
support whatever their users are using. If you're just telling the users
"sorry, PHP5 is not supported, we're waiting a year or 2 for version 6
because it has more bling-bling" then you can just as well stop with
your project because you're going to lose your entire community.

> Are you sure it's because it breaks BC? We don't know why people don't
> migrate.

Of course it's not just because of BC breakage but a lack of BC is
certainly not going to increase the percentage of PHP5 servers out
there. Besides BC is the fact that PHP5 is still relatively new, too
many small issues keep popping up and hosting providers are just really
conservative (and rightfully so). Just take a look at how long it took
before php3 was phased out.

> And for us, we didn't migra>te because *we* want to start with a
> new clean code base too, and not something hackish that just makes it
> work with PHP 5.

That's really cool for you but for 95% of the people out there this is
just not an option :\

> Yes, but it will also result in PHP being less and less competitive
> because we have to maintain all the old (broken) behavior (and make sure
> we never change anyting there).

That's just one side of it. If PHP isn't a stable platform then it's
also not going to be competitive. Being able to use your 'legacy' code
is pretty important for most people out there. It's certainly more
important (for the average end-user that wants a gallery or runs an
e-commerce site) than really new and cool OOP features. They (call them
the customer) don't care about that, they just want it to work and they
really can't be bothered by OOP or UTF8 as long as it works as expected.

Anyway. All I want to say is that you should IMO be careful with your
current user base. Trying to get them to use better/stricter/cleaner
coding practices is good as long as you're not just breaking 'bad' code.
Giving warnings (in E_STRICT) is good, it gives people time to adapt.
Just realize that people need a lot (really a lot) of time to adapt.

The main advantage that PHP has over other (better?) languages is that
it has a HUGE userbase, all the other web languages are dwarfed by the
size of PHP. This also means that there is a huge (really huge) amount
of 'old' code out there that people are using, you can't just discount
that. Losing this huge momentum can be rather fatal IMO.

But this is kind of straying from the original subject. In the end it's
all about where the benevolent dictators want the project to go. Do they
want a language that has the newest and coolest that programming has to
offer or do they want to provide a stable programming platform that has
inherited some flaws from the initial design? I don't know what they
want, I do know what I prefer :)

Bart

Lukas Smith

20 years ago

Bart van Bragt wrote:

> Derick Rethans wrote:
>
>> But who says your code should run on the new version? You don't *have*
>> to upgrade per se. It merely allows newly developed projects to run on
>> a cleaner version of PHP, which would undoubtfully also be faster
>> (because we wouldn't have any BC ballast).
>
> If I have a newly developed application then I can just as well go for
> something like RoR or Python or Java if I want something new and crispy
> with all the cool new features.

Java and cool new features in one sentence?

Anyways that the question we have to answer. Is PHP only value today its
installed user base? Or isnt there more to PHP that would make a cleaned
up PHP atleast as attractive? Also a cleaned up PHP would still be more
PHP than any other language out there. So its not like we will all have
to learn a new language.

> I don't want that, I want something that can be used by almost anyone
> with a webserver. I don't care (that much) for the new and cool things.

There is no licensing cost for either PHP nor its most used server
environment, namely Apache, so you can install as many distinct
instances you need.

> Sure it's very annoying that it's close to impossible to use (for
> instance) UTF8 in PHP but I'd rather be able to run my software just
> about anywhere with some restrictions in the language than being able to
> use all the new and cool stuff on just a few servers out there or with
> just a few clients. Skipping version 5 is just not an option for a LOT
> of people out there. Especially all the OS projects (phpBB, phpMyAdmin,
> Mambo, Gallery, Wordpress, etc, etc, etc) out there. They _have_ to
> support whatever their users are using. If you're just telling the users
> "sorry, PHP5 is not supported, we're waiting a year or 2 for version 6
> because it has more bling-bling" then you can just as well stop with
> your project because you're going to lose your entire community.

Most people are hesitant to upgrade because we give people the
impression that supposedly they should be able to run their old code in
new major versions. However at the same time we do admit that this is
not possible since we do break BC (even if these are actually bug or
design fixes) in several areas even in minor versions.

However if we lay down things clear and say:
Keep your old apps running in version X for now (just like what people
do today anyways as we can see in the slow adoption of PHP5), but here
is something new and shiny and its just like the PHP you have come to
love just cleaned from all the mess for any future projects, then
hosters will simply offer both the old and the new version if they want
to keep customers. This half-assed attempt at maintain BC is what is
really causing major problems.

I am not saying that we have to do major clean ups in every major
version of PHP, but every few major releases we should infact take this
opportunity. We should delay any BC breaks (be that they fix rare but
horrible bugs or design issues) as much as possible to these major
releases. We just have to communicate to our user base clearly when we
do break BC and when we actually do maintain BC. That way PHP remains
clean but also predictable.

>> Are you sure it's because it breaks BC? We don't know why people don't
>> migrate.
>
> Of course it's not just because of BC breakage but a lack of BC is
> certainly not going to increase the percentage of PHP5 servers out
> there. Besides BC is the fact that PHP5 is still relatively new, too
> many small issues keep popping up and hosting providers are just really
> conservative (and rightfully so). Just take a look at how long it took
> before php3 was phased out.
>
>> And for us, we didn't migra>te because *we* want to start with a new
>> clean code base too, and not something hackish that just makes it work
>> with PHP 5.
>
> That's really cool for you but for 95% of the people out there this is
> just not an option :\

Actually eZ is in the exact situation as 95% of the people out there,
since I presume the large majority of people run eZ Publish on shared
hosts or other servers where the users have either little control over
knowhow to keep the server using the latest and greatest.

>> Yes, but it will also result in PHP being less and less competitive
>> because we have to maintain all the old (broken) behavior (and make
>> sure we never change anyting there).
>
> That's just one side of it. If PHP isn't a stable platform then it's
> also not going to be competitive. Being able to use your 'legacy' code
> is pretty important for most people out there. It's certainly more
> important (for the average end-user that wants a gallery or runs an
> e-commerce site) than really new and cool OOP features. They (call them
> the customer) don't care about that, they just want it to work and they
> really can't be bothered by OOP or UTF8 as long as it works as expected.

See my note above. Everybody knows that clean ups will cause BC breaks
and everybody knows that designing code that never breaks BC is a futile
attempt that simply takes to long to be of any use out in the real
world. We just have to communicate more clearly when we do break BC and
we have to focus on reducing the number of BC breaking releases to a
minimum instead of breaking little things in every release.

> Anyway. All I want to say is that you should IMO be careful with your
> current user base. Trying to get them to use better/stricter/cleaner
> coding practices is good as long as you're not just breaking 'bad' code.
> Giving warnings (in E_STRICT) is good, it gives people time to adapt.
> Just realize that people need a lot (really a lot) of time to adapt.
>
> The main advantage that PHP has over other (better?) languages is that
> it has a HUGE userbase, all the other web languages are dwarfed by the
> size of PHP. This also means that there is a huge (really huge) amount
> of 'old' code out there that people are using, you can't just discount
> that. Losing this huge momentum can be rather fatal IMO.

As stated above .. if you reduce PHP appeal to its installed user base
we should just quit now and all stick with the java dinos. But notice
that java is having a hell of a time to keep its user base and I do not
think this is because they are breaking BC. Its because java has lots
its momentum (or hype machinery) to be the best tool for the job.

> But this is kind of straying from the original subject. In the end it's
> all about where the benevolent dictators want the project to go. Do they
> want a language that has the newest and coolest that programming has to
> offer or do they want to provide a stable programming platform that has
> inherited some flaws from the initial design? I don't know what they
> want, I do know what I prefer :)

Notice that the argument was not about the newest and coolest but about
dropping pasts mistakes. We can always pile on new cool features but
eventually we will just be crawling forward.

regards,
Lukas

Bart van Bragt

20 years ago

Lukas Smith wrote:

> See my note above. Everybody knows that clean ups will cause BC breaks
> and everybody knows that designing code that never breaks BC is a futile
> attempt that simply takes to long to be of any use out in the real
> world. We just have to communicate more clearly when we do break BC and
> we have to focus on reducing the number of BC breaking releases to a
> minimum instead of breaking little things in every release.

The 'communicate more clearly' part is what this (IMO) all boils down
to. As I said, I understand that BC breaks are sometimes needed, no
problem with that. The problem lies in the fact that we now all of the
sudden have lots of applications stopping with a fatal error because of
this '$ref =& $this' thing. That's just BAD. Give people time to create
workarounds for this (if the break is really needed) and make sure that
it's possible to keep your code working on all PHP versions that are
currently in use. There are quite a few workarounds for BC breaks in
phpBB, that's annoying but not a big problem as long as we're all given
time to implement those workarounds and as long as people get the
opportunity to upgrade to some new versions of the PHP software. That's
all :)

Try to prevent breaking BC in a rude way and communicate _clearly_ why
those changes are needed and why they can't be resolved in another way.
This could prevent things like this:
http://www.sitepoint.com/forums/showthread.php?t=299596
or:
http://phplens.com/phpeverywhere/?q=node/view/214
"However the PHP engine developers have done an extremely bad job in
explaining why many things that worked in earlier versions of PHP now
breaks, or why we are now getting "Fatal error/Warning: Only variables
can be passed by reference..." messages."
which are just bad for the community as a whole.

Bart

Lukas Smith

20 years ago

Bart van Bragt wrote:

> The 'communicate more clearly' part is what this (IMO) all boils down
> to. As I said, I understand that BC breaks are sometimes needed, no
> problem with that. The problem lies in the fact that we now all of the

I made a suggestion in regards to this a few days ago on this list.
However the mail went unanswered. So it goes.

> sudden have lots of applications stopping with a fatal error because of
> this '$ref =& $this' thing. That's just BAD. Give people time to create
> workarounds for this (if the break is really needed) and make sure that
> it's possible to keep your code working on all PHP versions that are
> currently in use. There are quite a few workarounds for BC breaks in

The point is that this is simply not feasible, neither on the php
developers end nor on the php users end, unless users put all your logic
into eval().

regards,
Lukas

Christian Schneider

20 years ago

Lukas Smith wrote:

> to keep customers. This half-assed attempt at maintain BC is what is
> really causing major problems.

The problem would be that this new PHP would be a wild mix of all
different changes. While I wouldn't mind a shiny new PHP with
&-references removed altogether which always copies object handles (as
Mike Ford calls them) and could live with public instead of var
everywhere I wouldn't like being forced to e.g. use exceptions if the
decision would be made to use them in the standard library.

So the whole package could go down the drain because of one part of it
(which  might be a different part for individual developers). The BC
approach works around this by allowing me to ignore new features I don't
want.

Two things to consider:
1) If the PHP maintainers are getting sick of BC then it might be better
to break BC than to lose maintainers.
2) On the other hand one should not forget that the amount of PHP4 code
around is much bigger than the size of the PHP source itself. So even if
BC is abandoned you can't simply drop PHP4 altogether (as hinted at in
this thread) without causing a lot of damage.

One possibility I see would be to have PHP<x> (insert your favourite
number here) drop compatibility with PHP4  and have some maintainers
work on PHP4 bug fixes and some on PHP6 features/bugs. It's kinda unclear
what would happen to PHP5 - PHP<x-1> though its maintainers would
face the same BC+new-stuff situation we have right now which doesn't
seem to be popular.

Trying to help deciding which way to go, ignore me if you don't care ;-)
- Chris

Jani Taskinen

20 years ago

On Tue, 4 Oct 2005, Christian Schneider wrote:

> Two things to consider:
> 1) If the PHP maintainers are getting sick of BC then it might be better
> to break BC than to lose maintainers.

Well, losing couple of trolls like me is not bad thing, is it? :)
But yes, if PHP can't evolve, this will happen. Either there will
be a fork of some sort or a "rogue" release of PHP 6..who knows.
We haven't decided yet. (any names for the fork are accepted :)

> 2) On the other hand one should not forget that the amount of PHP4 code
> around is much bigger than the size of the PHP source itself. So even if
> BC is abandoned you can't simply drop PHP4 altogether (as hinted at in
> this thread) without causing a lot of damage.

Nobody is talking about dropping PHP4. Definately no new features
will go into PHP 4, but bug fixes are still gonna be committed
once in a while. And as long as Derick is interested, there propably
will be even releases! :)

> One possibility I see would be to have PHP<x> (insert your favourite
> number here) drop compatibility with PHP4  and have some maintainers
> work on PHP4 bug fixes and some on PHP6 features/bugs. It's kinda unclear
> what would happen to PHP5 - PHP<x-1> though its maintainers would
> face the same BC+new-stuff situation we have right now which doesn't
> seem to be popular.

The Plan is to release 5.1 first by Ilia since the original RMs are too "busy".
We'll see what happens once we get rid of one of the branches to maintain,
the PHP_5_0 branch. (outdated, not holding all the fixes, etc.)

--Jani

--
Give me your money at @ <http://pecl.php.net/wishlist.php/sniper>
Donating money may make me happier and friendlier for a limited period!
Death to all 4 letter abbreviations starting with P!

Steph

20 years ago

--- and as was mentioned on IRC earlier, anyone who gives a damn about the
future of PHP isn't going to be someone who talks about forking it and
making rogue releases.  You _are_ trolling when you do this, and you're not
doing the reputation of the dev team any good.  I know you're one of the
good guys, I know you work like stink on the project and I know half of what
you say is tongue-in-cheek - but who else knows it?

Beside all that stuff, Jani, it's a Jewish religious holiday.  You're
attacking people who aren't around to defend themselves.  How cool is that?

Grrrr!

- Steph


----- Original Message -----
From: "Jani Taskinen" <sniper@iki.fi>
To: "Christian Schneider" <cschneid@cschneid.com>
Cc: <internals@lists.php.net>
Sent: Tuesday, October 04, 2005 11:43 PM
Subject: Re: [PHP-DEV] $ref =& $this;

> On Tue, 4 Oct 2005, Christian Schneider wrote:
>
> > Two things to consider:
> > 1) If the PHP maintainers are getting sick of BC then it might be better
> > to break BC than to lose maintainers.
>
>      Well, losing couple of trolls like me is not bad thing, is it? :)
>      But yes, if PHP can't evolve, this will happen. Either there will
>      be a fork of some sort or a "rogue" release of PHP 6..who knows.
>      We haven't decided yet. (any names for the fork are accepted :)
>
> > 2) On the other hand one should not forget that the amount of PHP4 code
> > around is much bigger than the size of the PHP source itself. So even if
> > BC is abandoned you can't simply drop PHP4 altogether (as hinted at in
> > this thread) without causing a lot of damage.
>
>      Nobody is talking about dropping PHP4. Definately no new features
>      will go into PHP 4, but bug fixes are still gonna be committed
>      once in a while. And as long as Derick is interested, there propably
>      will be even releases! :)
>
> > One possibility I see would be to have PHP<x> (insert your favourite
> > number here) drop compatibility with PHP4  and have some maintainers
> > work on PHP4 bug fixes and some on PHP6 features/bugs. It's kinda

unclear

> > what would happen to PHP5 - PHP<x-1> though its maintainers would
> > face the same BC+new-stuff situation we have right now which doesn't
> > seem to be popular.
>
>      The Plan is to release 5.1 first by Ilia since the original RMs are

too "busy".

>      We'll see what happens once we get rid of one of the branches to

maintain,

John Coggeshall

20 years ago

On Tue, 2005-10-04 at 09:49 +0200, Derick Rethans wrote:

> I am quite getting tired of having to maintain BC for *every* little
> stupid thing we ever did. I think it's time to start with a clean slate
> as it's all getting way to annoying to maintain (and know what subtle
> differences there are between PHP versions).

Amen.

John

Stanislav Malyshev

20 years ago

JC>>> I am quite getting tired of having to maintain BC for *every* little
JC>>> stupid thing we ever did. I think it's time to start with a clean slate
JC>>> as it's all getting way to annoying to maintain (and know what subtle
JC>>> differences there are between PHP versions).

The subtle differences are mostly because many of the developers don't
care for the BC. This leads to a state when if you code runs on x.y.z
version of PHP, you can't really be sure it would run on any other version
- and it works both ways, up and down. I think it's very bad for the users
and developers, and it leads to development time wasted and frustration
growing.

--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com  http://www.zend.com/ +972-3-6139665 ext.115

Peter Brodersen

20 years ago

Hi,

On Thu, 6 Oct 2005 12:26:30 +0300 (IDT), in php.internals
stas@zend.com (Stanislav Malyshev) wrote:

>The subtle differences are mostly because many of the developers don't
>care for the BC. This leads to a state when if you code runs on x.y.z
>version of PHP, you can't really be sure it would run on any other version
>- and it works both ways, up and down. I think it's very bad for the users
>and developers, and it leads to development time wasted and frustration
>growing.

Furthermore, some compatibility flags where a core function changes
behaviour could be a disservice as well. Even though they were meant
to ease a BC transition, you suddently can't be sure if your code runs
on any other servicer even if the x.y.z version is the same.

In some cases it could just result in Even Another Intial Ini-Check In
Your PHP Code.

--
- Peter Brodersen

Andi Gutmans

20 years ago

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
>
>--
>PHP Internals - PHP Runtime Development Mailing List
>To unsubscribe, visit: http://www.php.net/unsub.php

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