Re: PHP Alternative syntax

At 00:49 12-10-01, Jeroen van Wolffelaar wrote:

Jeroen, With all due respect, you do not deprecate *anything* that is not within your own code without having a clear, beyond-an-*un*reasonable-doubt understanding that the development team is behind this deprecation. A quick glance over my php-dev archive reveals not even a faint trace of a discussion regarding this issue. The discussion you refer to is a 1984-style history change. "The online manual says it's deprecated, so it is." Great, but who the heck changed the online manual? You did. Okay, I'm sorry that I noted it was deprecated, while I wasn't 100% about it. But I really had read it on the mailinglist, that people were saying so.

I'm not sure which mailing list that was, but at any rate, if you deprecate something, especially a feature which is all the way down in the language definition/syntax, you simply don't do it just like that (or at all).

I did assume people were following phpdoc commits, and since I didn't recieve any comments, I thought it was okay. I now know, and I aplogize once again, that no-comments definitely doesn't mean it's okay. There were quite a lot of old PHP3 things in the language section, including that false equals empty string, true doesn't exist and equals 1, etc etc. It was practically impossible to ask php-dev for everything, so I made logical assumptions every now and then. IMHO, the language section is quite improved, (though I'm still stuck in types, not further :-(... )

Please, don't document *anything* you're not 100.00% sure of about the core language syntax without consulting php-dev. Mis-documentation is worse than no documentation.

The documentation is already fixed a few days ago. I don't know wether it's a good place for a 'rectification', but I think it's indeed a good idea to re-add the warning box, with a text in the lines of: "This alternative syntax is particulary useful in including large chuncs of html. Be carefull with nesting alternative syntax. For normal code, {}-syntax is probably more clear (and more usual)"

I think the reassurance is quite necessary, considering the manual has (and apparently, still does) this feature misdocumented. You could warn about mixing it with the other syntax. However, sentence #1 does not belong in the box, and sentence #3 is your personal opinion and shouldn't be in the docs at all... I'm sorry if I sound angry, but it's probably because I kind-of am. We're all human though... Zeev