Are you supporting users who you provide a shared hosting embodiment too, and do you control binary installations on the enviroments? If so then possibly patching source for you installs maybe the easiest and quickest solution. If we knew the nature of your support requirements, then we could possibly suggest a better solution or be won round. (although internals isn't the place for that really)
This is not meant to bait but possibly an improvement in your support process or docs might yield a solution? -- James Butler Sent from my iPhone On 30 Oct 2010, at 17:51, "Chad Emrys" <ad...@codeangel.org> wrote: > On 10/30/2010 11:43 AM, James Butler wrote: >> If it ain't broken don't fix it. >> >> Change for the sake of it is a bad thing. It does things like introduce bugs >> etc. >> >> Q1) is it broken? >> Q2) if yes exactly what is broken >> Q3) does the proposes fix solve the root cause? >> >> I'm not sure changing the token name is the correct fix to people not >> knowing what the error means. >> >> -- >> James Butler >> Sent from my iPhone >> > Q1) yes, it is broken, people have to Google or ask around for a very > unclear error message when for the most parts errors are (and should be) > self explanatory. > > Q2) Two things are broken: Either the token is named badly, or the > token names shouldn't show up in error messages at all and be replaced > with something a bit more friendly. > > Q3) those two fixes above would probably fix that, yes. > > What is so hard to believe when people see UNEXPECTED T_DOUBLE_COLON on > LINE 23 they are gonna look for a double colon on line 23? because they DO. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
