Is there a technical reason <?= considered a "short tag"?

From: Date: Tue, 19 May 2009 00:33:00 +0000
Subject: Is there a technical reason <?= considered a "short tag"?
Groups: php.internals 
Request: Send a blank email to internals+get-44029@lists.php.net to get a copy of this message
From what I know, in the future versions of PHP short tags are going to be disabled by default. Considering the conflicts with XML syntax, that's understandable. However, is there a technical reason to consider <?= a short tag? From what I know, it doesn't conflict with XML notation, and it is really handy when writing templates. Moreover, keeping it independent from short tags settin is likely to decrease the number of scipts that will need to be rewritten, since some of them use the echo shortut without ever using vanilla <? (again, templates). I see this code in zend_language_scanner.l: <INITIAL>"<%="|"<?=" { if ((yytext[1]=='%' && CG(asp_tags)) || (yytext[1]=='?' && CG(short_tags))) { zendlval->value.str.val = yytext; /* no copying - intentional */ zendlval->value.str.len = yyleng; zendlval->type = IS_STRING; BEGIN(ST_IN_SCRIPTING); return T_OPEN_TAG_WITH_ECHO; } else { zendlval->value.str.val = (char *) estrndup(yytext, yyleng); zendlval->value.str.len = yyleng; zendlval->type = IS_STRING; return T_INLINE_HTML; } } Would it be possible to split this rule in two? <INITIAL>"<%=" { if ((yytext[1]=='%' && CG(asp_tags))) { zendlval->value.str.val = yytext; /* no copying - intentional */ zendlval->value.str.len = yyleng; zendlval->type = IS_STRING; BEGIN(ST_IN_SCRIPTING); return T_OPEN_TAG_WITH_ECHO; } else { zendlval->value.str.val = (char *) estrndup(yytext, yyleng); zendlval->value.str.len = yyleng; zendlval->type = IS_STRING; return T_INLINE_HTML; } } <INITIAL>"<?=" { zendlval->value.str.val = yytext; /* no copying - intentional */ zendlval->value.str.len = yyleng; zendlval->type = IS_STRING; BEGIN(ST_IN_SCRIPTING); return T_OPEN_TAG_WITH_ECHO; } If so, are are there any obvious negative consequences of doing so?

« previous php.internals (#44029) next »