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