# short_open_tag - Thread: https://externals.io/message/36246 - Original archive: https://news-web.php.net/php.internals/36246 - Started by Stanislav Malyshev on 2008-03-21T17:57:40+00:00 - Messages: 79 - Page 1 of 4: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/36246.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #36246 — Stanislav Malyshev — 2008-03-21T17:57:40+00:00 URL: https://externals.io/message/36246#36246 Hi! Forwarding this mail again since apparently many people missed it previously. Please discuss. -------- Original Message -------- Subject: short_open_tag Date: Fri, 07 Mar 2008 12:45:59 -0800 From: Stanislav Malyshev Hi! I wonder - is there a reason why short_open_tag config value is per-dir and not PHP_INI_ALL? After all, as I understand, it is private for each compilation. So suppose you preferred it generally off (you do XML, etc.) but you have some files in your app where you want it on - would there be any problem anywhere if it were INI_ALL? -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #36253 — Marcus Boerger — 2008-03-21T18:31:40+00:00 URL: https://externals.io/message/36246#36253 · In reply to: #36246 Hello Stanislav, thanks for rewriting this. Friday, March 21, 2008, 6:57:40 PM, you wrote: > Hi! > Forwarding this mail again since apparently many people missed it > previously. Please discuss. > -------- Original Message -------- > Subject: short_open_tag > Date: Fri, 07 Mar 2008 12:45:59 -0800 > From: Stanislav Malyshev > Hi! > I wonder - is there a reason why short_open_tag config value is per-dir > and not PHP_INI_ALL? After all, as I understand, it is private for each > compilation. So suppose you preferred it generally off (you do XML, > etc.) but you have some files in your app where you want it on - would > there be any problem anywhere if it were INI_ALL? For me the largest issue is infact late enabling of short tags at run time. The issue tracks down to the issue where peole might use code that enables short open tags but forgets to disable that. Now why might I rely on short open tags being disabled is another question of course. Years ago when we last discussed whether we should discourage them the conclusion was that not many people rely on them being off. Today many people have php code interact with XML code which sees short open tags as invalid PIs. Thus we should try to discourage maybe even finally deprecate short open tags. This would also be in line with the rest of PHP where we block and discourage short syntactical sugar when all it does is saving keystrokes. With short open tags the argument usually simply is that '' is shorther than writing ''. But then again the former is much harder to spot in manual written code. And for generated code it doesn't matter at all. That said I am against short open tags. And given my first part. I do not want to deal with code that does 'php_ini_set("short_open_tags", 0);' after every single include or require statement. Best regards, Marcus --- ## #36261 — Stanislav Malyshev — 2008-03-21T19:11:04+00:00 URL: https://externals.io/message/36246#36261 · In reply to: #36253 Hi! > For me the largest issue is infact late enabling of short tags at run time. > The issue tracks down to the issue where peole might use code that enables > short open tags but forgets to disable that. Now why might I rely on short I think this case is very unlikely. The use case for this feature is template system, written in long-tags style, but using short-tags notation for PHP templates. To compare: My name is and I am years old. My name is and I am years old. I think there's little doubt people - especially non-programmer people like designers - would have much less trouble understanding and writing first notation than second notation. If you compare larger, more complex templates, the difference in readability is even bigger. And having code easy to work with is one of the reasons people do PHP. Now, in a template system, it is really hard to imagine that template system creator would be so sloppy as to intend to write code like: setShortTags(); include $user_template; resetShortTags(); and somehow "forget" to write the last function. That would require extreme absent-mindedness on developer's part and you definitely should steer clear of template systems written by such people. However, for real template systems I know - they are written by very smart people, and actually these people support this capability, as it allows them to use nice syntax in templates without requiring any system configuration (which may be unavailable or incompatible with other code). > open tags being disabled is another question of course. Years ago when we This is very important question, since the only known case of why it might be important is when you use XML as template by including it directly through PHP parser. I don't think I would be mistaken if I say this is extremely rare use case. Actually, I'm not sure there's even one of common applications - like known CMSes, frameworks, blog platforms, e-commerce platforms, etc. - that can not work with short tags. Can you name which ones can't? Again, I consider the concept of "accidentally enabling" sort tags very improbable, but even if it somehow happened - IMO it would not be a problem except in some very rare use cases. > last discussed whether we should discourage them the conclusion was that > not many people rely on them being off. Today many people have php code And if you look at the discussion, there were opinions - including Zeev's - that there's nothing wrong with shorts tags in general, only in some rare use cases. > short syntactical sugar when all it does is saving keystrokes. With short > open tags the argument usually simply is that '' is shorther than > writing ''. But then again the former is much harder to > spot in manual written code. And for generated code it doesn't matter at I have hard time figuring out a use case when you need to "spot" this in your code - and, indeed, have one in your code at all, unless it is a template. In a template, all. That said I am against short open tags. And given my first part. I do > not want to deal with code that does 'php_ini_set("short_open_tags", 0);' > after every single include or require statement. You do not need to deal with this code, and there's absolutely no reason to do it. Only case when you may need to do it if you include *hostile* code - i.e. code that can intentionally try and screw up your environment. In this case, this code might do much worse things than screw with your short tags setting, which in 99.99% of cases wouldn't do anything - that code might drop your include path, unset your variables, close your files and DB connections, reset your memory limit and execution time to very low values, rewire charsets on input and output, install any kinds of stream filters, turn on magic quotes, and do a ton of other very bad things like messing with your file system and what not. Still all those variables and settings are user-accessible. And you are not worried about restoring your include path or resetting your magic quotes or memory limits after each include. And on top of that - if you are still concerned, you always could do php_admin_value which IIRC blocks setting values by user. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #36262 — Jani Taskinen — 2008-03-21T19:27:59+00:00 URL: https://externals.io/message/36246#36262 · In reply to: #36261 Stanislav Malyshev kirjoitti: > I think this case is very unlikely. The use case for this feature is > template system, written in long-tags style, but using short-tags > notation for PHP templates. To compare: > > My name is and I am years old. > > My name is and I am years old. I'd rather see Hi! > > […] > I think this case is very unlikely. The use case for this feature is > template system, written in long-tags style, but using short-tags > notation for PHP templates. To compare: > My name is and I am years old. > My name is and I am years old. > I think there's little doubt people - especially non-programmer people > like designers - would have much less trouble understanding and writing > first notation than second notation. If you compare larger, more complex > templates, the difference in readability is even bigger. And having code > easy to work with is one of the reasons people do PHP. But the non programmers don't understand either. And instea of promoting Now, in a template system, it is really hard to imagine that template > system creator would be so sloppy as to intend to write code like: > setShortTags(); > include $user_template; > resetShortTags(); > and somehow "forget" to write the last function. That would require > extreme absent-mindedness on developer's part and you definitely should > steer clear of template systems written by such people. However, for > real template systems I know - they are written by very smart people, > and actually these people support this capability, as it allows them to > use nice syntax in templates without requiring any system configuration > (which may be unavailable or incompatible with other code). > > […] > This is very important question, since the only known case of why it > might be important is when you use XML as template by including it > directly through PHP parser. I don't think I would be mistaken if I say > this is extremely rare use case. Actually, I'm not sure there's even one > of common applications - like known CMSes, frameworks, blog platforms, > e-commerce platforms, etc. - that can not work with short tags. Can you > name which ones can't? > Again, I consider the concept of "accidentally enabling" sort tags very > improbable, but even if it somehow happened - IMO it would not be a > problem except in some very rare use cases. > > […] > And if you look at the discussion, there were opinions - including > Zeev's - that there's nothing wrong with shorts tags in general, only in > some rare use cases. That is more than 5 years ago though. > > […] > I have hard time figuring out a use case when you need to "spot" this in > your code - and, indeed, have one in your code at all, unless it is a > template. In a template, very easy to spot. Nope, the shorter the sequence to look for the harder. > > […] > You do not need to deal with this code, and there's absolutely no reason But I do not have to use something is no reason to add a function. > And on top of that - if you are still concerned, you always could do > php_admin_value which IIRC blocks setting values by user. But I don't want to add more stuff to make sure my stuff works. I want it infact easier with less configurations. Best regards, Marcus --- ## #36263 — Stanislav Malyshev — 2008-03-21T19:37:18+00:00 URL: https://externals.io/message/36246#36263 · In reply to: #36262 > I'd rather see I'd even use it myself. But I will not EVER enable the damn short tags > again. And won't allow anyone else doing it either. And speaking of What's wrong with short tags, can anybody explain me? > hostile code: ALL code is hostile unless you wrote it yourself. Have you Not true. You probably use a ton of libraries, never verifying they don['t screw up your include path, memory limits, etc.? Why short tags are so different? > And as you yourself instructed to check for "short_open_tag" in the > archive search: Count how many hits it gives which talk about _problems_ > with it. Can you show which exactly search query you used, so we'd be sure we are talking about the same thing? -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #36265 — Stanislav Malyshev — 2008-03-21T19:44:04+00:00 URL: https://externals.io/message/36246#36265 · In reply to: #36264 Hi! > But the non programmers don't understand either. And instea They do. "Non programmer" != "idiot". > of promoting to XML. See my previous mail on that. > That is more than 5 years ago though. OK, so? > But I do not have to use something is no reason to add a function. I never brought it as a reason to add. The reason is the use case we already discussed. > But I don't want to add more stuff to make sure my stuff works. I want it > infact easier with less configurations. In real use cases, you won't need any configurations at all. In imaginary use case where you are beset by hostile includes that are determined to ruin your environment and incompetent library writers that can't write 3 lines of code, but you must use their libraries, and on top of that you absolutely must to include XML files into the same application - in this imaginary case you still have very easy solution that allows you to go back to pre-patch state. I wish all patches could be reverted as easily when needed. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #36267 — Marcus Boerger — 2008-03-21T19:44:58+00:00 URL: https://externals.io/message/36246#36267 · In reply to: #36263 Hello Stanislav, Friday, March 21, 2008, 8:37:18 PM, you wrote: > > […] > Does be template systems couldn't use it until 5.3 is widely deployed - which > means no template system can use it as standard for about 2-3 years at > least. Unless we put but might be a trouble for others. The problem with ' > […] > > Does least. Unless we put but might be a trouble for others. I wouldn't mind. Nor would couple of thousand other people. :) > > […] > > What's wrong with short tags, can anybody explain me? [see below where you ask about the archive search..] > > […] > > Not true. You probably use a ton of libraries, never veerifying they > don['t screw up your include path, memory limits, etc.? Why short tags > are so different? Nobody can set memory_limit in a script during runtime. AFAICT. Short tags are language SYNTAX issue. That's why it's different. You don't get any plain error if they're "on" and something doesn't work. It just doesn't work or misbehaves. > > […] > > Can you show which exactly search query you used, so we'd be sure we are > talking about the same thing. Just plain "short_open_tag" (without the quotes of course :). Here's the longish url: http://www.mail-archive.com/find.php?domains=www.mail-archive.com&q=short_open_tag&sa=Search+mailing+lists&sitesearch=www.mail-archive.com&client=pub-7266757337600734&forid=1&channel=2703820358&ie=ISO-8859-1&oe=ISO-8859-1&cof=GALT%3A%23C8C8C8%3BGL%3A1%3BDIV%3A%23CD9685%3BVLC%3A000000%3BAH%3Acenter%3BBGC%3AFFFFFF%3BLBGC%3AFFFFFF%3BALC%3A006792%3BLC%3A006792%3BT%3A000000%3BGFNT%3A006792%3BGIMP%3A006792%3BFORID%3A11&hl=en The first hits explain quite well why short_open_tag is bad, mmkay. --Jani --- ## #36268 — Pierre Joye — 2008-03-21T19:48:03+00:00 URL: https://externals.io/message/36246#36268 · In reply to: #36263 > > […] > > Does be template systems couldn't use it until 5.3 is widely deployed - which > means no template system can use it as standard for about 2-3 years at > least. Unless we put but might be a trouble for others. > > > > […] > > What's wrong with short tags, can anybody explain me? The main reason is that they are not valid processing instructions. See http://www.w3.org/TR/REC-xml/#sec-pi Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #36269 — Stanislav Malyshev — 2008-03-21T20:02:50+00:00 URL: https://externals.io/message/36246#36269 · In reply to: #36266 > The first hits explain quite well why short_open_tag is bad, mmkay. OK, let's see what we have there: 0. Support for my email, skipping. 1. "The web is a rapidly changing market and standards are being activley evolved. The main reason is that they are not valid processing instructions. > See http://www.w3.org/TR/REC-xml/#sec-pi Great, they are also probably not valid S-expressions and not valid phrases in Mandarin. Why they are bad because of that? Is there any requirement for them to be? -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #36271 — Stanislav Malyshev — 2008-03-21T20:08:02+00:00 URL: https://externals.io/message/36246#36271 · In reply to: #36267 > However the ' like ' > […] > Great, they are also probably not valid S-expressions and not valid > phrases in Mandarin. Why they are bad because of that? Is there any > requirement for them to be? The argument being? Best regards, Marcus --- ## #36272 — Pierre Joye — 2008-03-21T20:13:05+00:00 URL: https://externals.io/message/36246#36272 · In reply to: #36269 > No explanation why it "shows lazyness" or why it's bad except for > hinting it's somehow bad for handling XML (which it isn't). See below. > Should I go deeper? Did we use the same search engine? I'm still missing > explanation why short tags are bad. I gave you the link to one main explanation, the XML specs. Or what else do you need to explain the problem in the XML context? -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #36277 — Marcus Boerger — 2008-03-21T20:13:45+00:00 URL: https://externals.io/message/36246#36277 · In reply to: #36271 Hello Stanislav, Friday, March 21, 2008, 9:08:02 PM, you wrote: > > […] > trouble. If we had something short and nice like would make PHP templates look clean, but doing Nobody can set memory_limit in a script during runtime. AFAICT. Why? It's INI_ALL. So is, for example, include_path. > Short tags are language SYNTAX issue. That's why it's different. > You don't get any plain error if they're "on" and something doesn't work. > It just doesn't work or misbehaves. In 99.999% of cases you'd get parse error on first I gave you the link to one main explanation, the XML specs. Or what > else do you need to explain the problem in the XML context? I need to explain why XML specs have any relevance to PHP syntax and why PHP sources should conform to them. Are we coding in XML now? Is everybody using an XML parser to process PHP code? How XML spec is one to dictate what PHP syntax is? -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #36276 — Stanislav Malyshev — 2008-03-21T20:16:08+00:00 URL: https://externals.io/message/36246#36276 · In reply to: #36273 > > […] > > The argument being? Why they are bad because of that? Is there any requirement for them to be? -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #36278 — Pierre Joye — 2008-03-21T20:17:52+00:00 URL: https://externals.io/message/36246#36278 · In reply to: #36270 > > […] > > Great, they are also probably not valid S-expressions and not valid > phrases in Mandarin. Why they are bad because of that? Is there any > requirement for them to be? PHP works more and more in a multi cultural environment (php, jsp, xml, etc.). One of the goals of a standard is to avoid conflicts, buggy behavior or system specific features. PHP works with XML in many cases, xhtml growing usage is one good example. I'm very surprised to have to discuss this problem once again in this list. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #36279 — Marcus Boerger — 2008-03-21T20:23:10+00:00 URL: https://externals.io/message/36246#36279 · In reply to: #36275 Hello Stanislav, lemme think, PHP is used to generate HTML and XHTML. And often people have the headers outside of the PHP tags. And some people like to use tools. But maybe I am wrong. Either way. It appears that nearly every single person replying is against this. So can we please stop arguing? I don't think there are more arguemnts coming. And it doesn't look like you are convincing anyone here. Maybe instead work on a proposal for something like > […] > I need to explain why XML specs have any relevance to PHP syntax and why > PHP sources should conform to them. Are we coding in XML now? Is > everybody using an XML parser to process PHP code? How XML spec is one > to dictate what PHP syntax is? Best regards, Marcus --- ## #36280 — Stanislav Malyshev — 2008-03-21T20:30:23+00:00 URL: https://externals.io/message/36246#36280 · In reply to: #36277 > The thing is that And if you ronly argument is saving a few keystrokes then we should really > get rid of short open tags completely. And definitively not making their > use easier. It is easier to use templates with then with full PHP syntax, they look cleaner. Just look how many other templates use "tag" syntax - either {SOMETHING} or <%= SOMETHING %> or some like that. Do you that's because they are too stupid or too lazy - or because they listen to the users? ASP, JSP and Ruby all have <%=, does it teach us anything about people liking short tags? Look how many examples you short syntax - why is that? Because it looks better and easy to read. And the only objection to that is - it's not valid XML. OK, it is not valid XML - why should it be? Why should PHP programmer work harder and PHP code look worse than Ruby, JSP or ASP - just because of arbitrary requirement of XML compliance? -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #36281 — Stanislav Malyshev — 2008-03-21T20:32:48+00:00 URL: https://externals.io/message/36246#36281 · In reply to: #36278 > PHP works more and more in a multi cultural environment (php, jsp, > xml, etc.). One of the goals of a standard is to avoid conflicts, Great. So let's see when there could be a conflict. Only way there could be a conflict is when XML is included as PHP source. Now, how frequently one really needs to do that? > buggy behavior or system specific features. PHP works with XML in many > cases, xhtml growing usage is one good example. I'm very surprised to > have to discuss this problem once again in this list. You sound like it was discussed and the decision was in your favor. Well, it wasn't - read the summary I just made from the archives. So if you want to declare "case closed" - fine, but it's closed in favor of short tags. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #36282 — Stanislav Malyshev — 2008-03-21T20:37:51+00:00 URL: https://externals.io/message/36246#36282 · In reply to: #36279 > lemme think, PHP is used to generate HTML and XHTML. And often people Neither of which require have the headers outside of the PHP tags. And some people like to use tools. > But maybe I am wrong. Either way. It appears that nearly every single > person replying is against this. So can we please stop arguing? I don't You mean like 3 people that can't even explain why they hate short tags, but just like me to shut up because their opinion can't be wrong? Yeah, right. > think there are more arguemnts coming. And it doesn't look like you are > convincing anyone here. Maybe because these "someone" just can't be convinced by rational argument. This is really sad that people are willing to sacrifice interests of the users and the language development for... well, I don't even know for what. For not admitting they were wrong for once? -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #36283 — Marcus Boerger — 2008-03-21T20:41:39+00:00 URL: https://externals.io/message/36246#36283 · In reply to: #36281 Hello Stanislav, Friday, March 21, 2008, 9:32:48 PM, you wrote: > > […] > Great. So let's see when there could be a conflict. Only way there could > be a conflict is when XML is included as PHP source. Now, how frequently > one really needs to do that? There is also an issue when I want to verify my stuff using XML tools. Best regards, Marcus --- Next page: https://externals.io/message/36246.md?page=2