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