On Fri, Jul 23, 2010 at 9:40 AM, Reindl Harald <h.rei...@thelounge.net>wrote:
> First: > A personally answer is NOT "the list" > > Am 23.07.2010 17:27, schrieb Karoly Negyesi: > >> Idiotic point of view, really there is no brain behind > > > > Really? so we are now down to personal attacks. > > Sorry but if you do not understand the first answer i have > to make it clear > > > Now listen. *Every* > > PHP version breaks backwards compatibility > > But NEVER without any reason > > Nobody, bever in no project has to make incompatible > changes just for fun > > > I am one of the lead Drupal developers > > no comment > > > It was quite long ago but > > didnt PHP 4.4 break array functions not to accept NULLs instead > > of empty arrays? > > If this was a problem the code is crap > ARRAY-functions are expecting arrays, if the do not > loud cry by other input does not mean the input is ok > > > Now, PHP 5.3 breaks things so big time it really should > > have been PHP 6.0 because this sets up an expectation that everything > > that worked with 5.2 works with 5.3 because it's not a major change. > > Still: we cope as best as we can. > > What does 5.3 break? > Because you application is not well designed and you have > troubles you want a incomaptible change to break other > applications? > > Our core project has 250.000 LOC and get it running with 5.3 > needed only 6 changes to get aways some warnings > > 122 production installations with error_reporting E_ALL including E_STRICT > > If 5.3 breaks things that you would like to call it 6.0 > think about your code as some other projects should do > which are writing thousands of warnings in dhe log with > E_STRICT, E_DEPRECATED, E_ALL > > > I have pointed out why it's confusing which apparently noone read > > and have pointed out that there is an equivalent replacement which > > again noone read because someone asked whether I want to remove > > call_user_func too which is the very alternative I have pointed out. > > Does not matter > If you will remove everything that can confuse anybody you > have to remove nearly all things which are powerful but this > is a bad idea because you will every time have a user with missing > skills which is confused > > > I have refrained from writing to this mailing list for years. It's > > crystal clear again that feedback is not welcome, my emails are not > > read and now I am personally attacked so I will stop here and revert > > to lurking. You guys can continue breaking the language and make our > > life hell. I tried. > > stop to whine! > > It is not "the list" if you get a personally answer for > breandead wishes they have only the reason to break others > projects because yours is broken with 5.3 and you will > see die other ones too > > Reindl is correct in one thing: The tone of his emails is not representative of this list. I don't think your suggestion is "braindead", but I also don't think it's something PHP should do. It's obvious you're not worried about developers working on the core of drupal, but about the developers further downstream, that you have no control over, yet their bugs are reported to you. It sounds like the only case you wish to change is $foo(). "new $foo()" and "classname::$bar()" would be left alone. However, there are rules defining the behavior of all the cases you have cited, and they've been in use for quite some time. There's a lot of code out there that uses it. There are plenty of useful things in PHP that can be misused or misunderstood, but the fact that a feature can be misused or misunderstood is not a good enough reason to remove it. The fact that new(ish) functionality now can replace the old functionality adds to your argument, but is outweighed by the sheer weight of code out there that uses the older syntax. John
