[PHP-DEV] $ref =& $this;
Derick Rethans
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
Marcus Boerger
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
Pierre
der...@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
> 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 Boerger
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
Richard Mann
$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 <he...@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.
====================================================================
Dmitry Stogov
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.
> regards,
> Derick
>
> --
> Derick Rethans
> http://derickrethans.nl | http://ez.no | http://xdebug.org
>
Marcus Boerger
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
> Hi,
> Thanks. Dmitry.
Best regards,
Marcus
Jason Sweat
> 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
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 =3D&
$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
BC is working. PHP5 has zend.ze1_compatibility_mode and some PHP
applications use it.
BTW to disallow =3D& $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.
> -----Original Message-----
> From: Marcus Boerger [mailto:he...@php.net]=20
> Sent: Monday, October 03, 2005 6:14 PM
> To: Dmitry Stogov
> Cc: 'Derick Rethans'; 'PHP Developers Mailing List'
> Subject: Re: [PHP-DEV] $ref =3D& $this;
>=20
>=20
> Hello Dmitry,
>=20
> that IS NOT proper code and it wasn't in php 4 either, it=20
> was only a workaround that is no longer needed. Had the php 4=20
> design been correct in the first place that wouldn't have=20
> been allowed in 4 either. Since BC is not working out anyway=20
> i see absolutley no reason to encourage people to continue to=20
> missuse php.
>=20
> marcus
>=20
> Monday, October 3, 2005, 4:05:56 PM, you wrote:
>=20
> > Hi,
>=20
> > At first $ref =3D& $this; produced fatal error because of the=20
> bug (not=20
> > by design). For example $ref->prop =3D& $this; worked and=20
> works without=20
> > errors.
>=20
> > So my patch shouldn't be reverted in any case.
>=20
> > At second disallowing such assignments and passign $this by=20
> reference=20
> > will breake a lot of PHP4 code (Mamaba CMS). In PHP4=20
> passing $object=20
> > by refernce and by value had completely different semantic.
>=20
> > I don't see any reason to disallow 100% proper code (like the the=20
> > following).
>=20
> > class Child {
> > function Child($parent) {
> > $parent->children[] =3D& $this;
> > }
> > }
>=20
> > Of course using "=3D& $this" user can breake $this value, but other=20
> > languages
> > (C++) allows this too.
> > I don't think we should be paranoiacs.
>=20
> > Thanks. Dmitry.
>=20
>=20
> >> -----Original Message-----
> >> From: Derick Rethans [mailto:der...@php.net]
> >> Sent: Monday, October 03, 2005 5:09 PM
> >> To: PHP Developers Mailing List
> >> Subject: [PHP-DEV] $ref =3D& $this;
> >>=20
> >>=20
> >> Hello,
> >>=20
> >> Dmitry committed a fix earlier to ignore the & in the
> >> statement above. I=20
> >> think this is not a good thing to do as it's simply=20
> >> conceptually wrong.=20
> >> The first thing is that ignoring syntax without issuing a=20
> warning is=20
> >> dubious because people might think it does actually work, and=20
> >> secondly=20
> >> because I think that the code above is wrong anyway -=20
> somewhat in the=20
> >> same way that "$this =3D new foo();" is wrong.
> >>=20
> >> There is never any need to assign $this by reference, nor to
> >> pass it by=20
> >> reference to a function as it's an object anyway, making the=20
> >> references=20
> >> pointless - I would even go as far as disallowing passing $this by=20
> >> references to a function - where the reference has to be=20
> >> ignored again,=20
> >> otherwise it allows you to chantge $this to a different=20
> object with:
> >>=20
> >> class Foo {
> >> function byRef(&$f) {
> >> $f =3D new Bar();
> >> }
> >>=20
> >> function modifyThis() {
> >> $this->byRef($this);
> >> }
> >> }
> >>=20
> >> I think we should prevent people from writing syntax like
> >> this, as it is=20
> >> not obvious what is going to happen. This means that we=20
> should revert=20
> >> Dmitry's patch.
> >>=20
> >> regards,
> >> Derick
> >>=20
> >> --
> >> Derick Rethans
> >> http://derickrethans.nl | http://ez.no | http://xdebug.org
> >>=20
> >> --
> >> PHP Internals - PHP Runtime Development Mailing List
> >> To unsubscribe, visit: http://www.php.net/unsub.php
> >>=20
> >>=20
>=20
>=20
>=20
>=20
> Best regards,
> Marcus
>=20
> --=20
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>=20
>=20
Christian Schneider
> 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
Andi Gutmans
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/
Andi Gutmans
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:der...@php.net]
> >> Sent: Monday, October 03, 2005 5:09 PM
> >> To: PHP Developers Mailing List
>Best regards,
> Marcus
Andi Gutmans
If it's the latter then it is a problem (and it's the reason I didn't
support it to begin with).
Andi
Marcus Boerger
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
Robert Cummings
> On Mon, 3 Oct 2005, Richard Mann wrote:
>
> > Hmmm.... I agree about the reassigning of $this, but not the passing of
> > $this by ref.
>
> 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
> 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.
Rasmus Lerdorf
> 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
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
> 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
--
Derick Rethans
> 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,
Marcus Boerger
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
Marcus Boerger
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.
Jani Taskinen
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT
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損u新ion:
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!
--8323328-168867287-1128413018=:32051
Content-Type: text/plain; charset=us-ascii
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--8323328-168867287-1128413018=:32051--
Christian Schneider
> 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
Christian Schneider
> On Tue, 4 Oct 2005, Christian Schneider wrote:
>> And the code _does_ work with PHP5.
>
> il損u新ion:
> 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 ;-)
Michael Wallner
> Hello Derick,
>
>
>>Yes, but thinking that PHP 4 "OO" code runs on PHP 5 is an illusion
>>anyway.
>
>
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 >
Jani Taskinen
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT
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損u新ion:
>> 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!
--8323328-1376371491-1128415030=:32051
Content-Type: text/plain; charset=us-ascii
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--8323328-1376371491-1128415030=:32051--
Christian Schneider
> 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
> 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
--
Dmitry Stogov
$var =3D & $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 =3D& $this;
$x =3D null;
var_dump($this);
$this->x =3D 2;
}
}
$x =3D 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 =3D &$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:he...@php.net]=20
> Sent: Tuesday, October 04, 2005 12:03 PM
> To: Derick Rethans
> Cc: Dmitry Stogov; 'PHP Developers Mailing List'
> Subject: Re: [PHP-DEV] $ref =3D& $this;
>=20
>=20
> Hello Derick,
>=20
> Tuesday, October 4, 2005, 9:49:00 AM, you wrote:
>=20
> > On Mon, 3 Oct 2005, Dmitry Stogov wrote:
>=20
> >> At second disallowing such assignments and passign $this=20
> by reference=20
> >> will breake a lot of PHP4 code (Mamaba CMS). In PHP4=20
> passing $object=20
> >> by refernce and by value had completely different semantic.
>=20
> > Yes I know. In PHP 4 the OO was totally crap, and now you're saying=20
> > you
> > want to keep "bogus" behavior for eternity so that all the=20
> PHP 4 apps=20
> > can still run?
>=20
> No. And it is even worse. We start maintaining BC for things=20
> we always agreed we do not support - just because some crazy=20
> app used this for a workaround of a problem they couldn't=20
> solve? Maybe they should have asked for the fature - but the=20
> 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.
=20
> > 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=20
> clean slate=20
> > as it's all getting way to annoying to maintain (and know=20
> what subtle=20
> > differences there are between PHP versions).=20
>=20
> > 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=20
> way possible.=20
> > Now we get code like this:
>=20
> > if (Z_TYPE_PP(str) =3D=3D IS_UNICODE) {
> > php_u_trim(Z_USTRVAL_PP(str), Z_USTRLEN_PP(str),=20
> > Z_USTRVAL_PP(what), Z_USTRLEN_PP(what), return_value, mode=20
> TSRMLS_CC);
> > } else {
> > php_trim(Z_STRVAL_PP(str), Z_STRLEN_PP(str),=20
> > Z_STRVAL_PP(what), Z_STRLEN_PP(what), Z_TYPE_PP(str),=20
> return_value, mode TSRMLS_CC);
> > }
>=20
> > Which is in my opinion totally unmaintainable in the long run. I=20
> > really
> > think we would be much better of to get rid of IS_STRING=20
> and only have=20
> > IS_BINARY and IS_UNICODE - do it the nice and clean way and=20
> forget about=20
> > BC. We would definitely see the benefits in the long run.
>=20
> That's what i said directly when first looking at the current=20
> unicode implementation. It is absolute unmaintainable for any=20
> non full time php-c code developer. We have tons of "_u_"=20
> function name inlays and thousands of macros and i am quite=20
> sure none of that is necessary.=20
I agree about unicode support implementation.
I did a lot of work on it, but I don't like it.
Dmitry.
> And for instance right no i=20
> still have absolutley no idea of what is going on. And by=20
> looking at the hundreds of warnings - well other don't do=20
> either - not even in the engine code. And don't tell me=20
> "warnings". Yesturday i fixed at least one that was a real=20
> error and seeing hundres of warnigns in our code makes me=20
> blind - It makes me ignore the help the compiler could give=20
> me. And believe me i write warning free code for a reason.
>=20
> >>=20
> >> I don't see any reason to disallow 100% proper code (like the the=20
> >> following).
> >>=20
> >> class Child {
> >> function Child($parent) {
> >> $parent->children[] =3D& $this;
> >> }
> >> }
> >>=20
> >> Of course using "=3D& $this" user can breake $this value, but other =
> >> languages
> >> (C++) allows this too.
>=20
> A reference in C++ is a very different thing. And especially=20
> it doesn't allow you to fuck up any instance or cause memory=20
> corruption or invalid variables. If you don't understand c++=20
> don't use it here.
>=20
> > So if C++ allows this we should too? I think that's one invalid=20
> > reason.
> > There is no point of assigning by reference here, so we=20
> shouldn't allow=20
> > that. That way our users see "oh, I did something wrong,=20
> let's fix it" -=20
> > and yes, it will break BC. But the OO model in PHP 5 is totally=20
> > different than in PHP 4, so I see no problems with that.
>=20
> And right now before 5.1 comes out we still have the choice.=20
> If i consider all the arguments i have heared then only a=20
> handfull of people must be using php 5 right now and there=20
> mostly for testing or for running php 4 code maybe a little=20
> bit adapter, like changing var public.
>=20
>=20
> Best regards,
> Marcus
>=20
>=20
Bart van Bragt
> I am quite getting tired of having to maintain BC for *every* little
> as it's all getting way to annoying to maintain (and know what subtle
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
> 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
Edin Kadribasic
> 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
Gareth Ardron
> 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.
Bart van Bragt
> 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.
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
> 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
--
Derick Rethans
> 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,
Bart van Bragt
> 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).
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
Ford, Mike
> 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 =3D &$this issue, only that $obj =3D $someObj is NOT the same as
> $obj =3D &$someObj.=20
Yes, very true. I've mentioned before that I think PHP 5's object thingumm=
ies should be referred to as "handles" (and I'm sure I actually saw this us=
age in early versions of the PHP 5 or Zend Engine 2 proposals). Then, it's=
much clearer that:
$obj2 =3D $obj1
gives you a copy of the object handle, but:
$obj2 =3D &$obj1
gives you a reference to the handle.
Cheers!
Mike
---------------------------------------------------------------------
Mike Ford, Electronic Information Services Adviser,
Learning Support Services, Learning & Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Headingley Campus, LEEDS, LS6 3QS, United Kingdom
Email: m.f...@leedsmet.ac.uk
Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211=20
To view the terms under which this email is distributed, please go to http:=
//disclaimer.leedsmet.ac.uk/email.htm
Lukas Smith
> 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
> 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.
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
John Coggeshall
> 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
Lukas Smith
> 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
Oliver Grätz
> Yes, very true. I've mentioned before that I think PHP 5's object thingummies should be referred to as "handles" (and I'm sure I actually saw this usage in early versions of the PHP 5 or Zend Engine 2 proposals). Then, it's much clearer that:
>
> $obj2 = $obj1
>
> gives you a copy of the object handle, but:
>
>
> gives you a reference to the handle.
From the point of view of an ordinary programmer: He's so right: It is
absolutely clear! You _must_ put this in the official documentation!
I knew what was happening before but up to this few words I could not
put it down in words. Thank you, Mike!
AllOLLi
____________
Simon: "So what are we doing?"
Kaylee: "Oh! Crime."
Simon: "Crime, good. Okay. Crime."
[firefly 02]
Friedhelm Betz
> Ford, Mike schrieb:
>
>> Yes, very true. I've mentioned before that I think PHP 5's object
>> thingummies should be referred to as "handles" (and I'm sure I
>> actually saw this usage in early versions of the PHP 5 or Zend
>> Engine 2 proposals). Then, it's much clearer that:
>>
>> $obj2 = $obj1
>>
>> gives you a copy of the object handle, but:
>>
>> $obj2 = &$obj1
>>
>> gives you a reference to the handle.
>
>
>> From the point of view of an ordinary programmer: He's so right: It
>> is
> absolutely clear! You _must_ put this in the official documentation!
> I knew what was happening before but up to this few words I could not
> put it down in words. Thank you, Mike!
Bug reports for documentation can be reported at bugs.php.net as
"Documentation Problem"
Regards
Friedhelm
Oliver Grätz
> 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
Marcus Boerger
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?
Marcus Boerger
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
Christian Schneider
> 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
> 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
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
Andi Gutmans
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:
> > 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
Zend/PHP Conference & Expo
Power Your Business with PHP
October 18-21, 2005 - San Francisco
http://zend.kbconferences.com/
Steph
> until other people see what mess we're getting in - but they won't.
A split is far from being the best option. There are too many users out
there to make it even a sane option. Or did you plan on getting rid of
those entirely? :-)
> > 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?
>
> Are those 3 weeks long? Come on... And it's also not the first time they
> skipped out.
Actually, this October the holidays pretty much _are_ 3 weeks long... and
FWIW I don't think you see one half of the work 'they' do until it's done.
- Steph
Steph
> 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?
Rasmus Lerdorf
> 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
Lukas Smith
> 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