| View previous topic :: View next topic |
| Author |
Message |
messju
Administrator
Joined: 16 Apr 2003
Posts: 3336
Location: Oldenburg, Germany
|
 Posted: Thu Oct 23, 2003 9:24 pm Post subject: |
 |
|
sorry for my blindness and/or ignorance.
what is the benefit from {($a+$b)} against {$a+$b} ?
i'm all for *allowing* parenthesis, but i don't see any advantage in *forcing* them. if the only advantage in parenthesis is a potential simplification in the underlying implementation (as a hinting for the compiler to expect math, for example) i'm against them.
if we add parenthesis we shouldn't get too far away from common sense about them. to me that would be: only force them to remove ambiguities or use them to overule default-precedence and -associativity of constructs.
to get things right (IMHO) that would mean that parenthesis not only denote expressions but also seperate sub-expressions. that would mean
{"`($a+$b)`"} but also {$foo.($bar.baz)} or maybe {$var|mod:($arg|succ)}.
i know that's not the easiest way to do this, but IMHO it's the most viable one if we occupy the "(" and ")" chars syntactically. |
|
| Back to top |
|
mohrt
Administrator
Joined: 16 Apr 2003
Posts: 7368
Location: Lincoln Nebraska, USA
|
| Posted: Thu Oct 23, 2003 9:50 pm Post subject: |
|
|
| My initial thoughts behind the parenthesis were to avoid possible systax ambiguities, now and the forseeable future. However, parenthesis can already be used in object calls and {if} statements, so this may not work anyways. If this last patch works ok, maybe we'll just keep what we've got. By the modular nature of the regex engine I'll bet some of this syntax already works in other places, such as modifiers. |
|
| Back to top |
|
messju
Administrator
Joined: 16 Apr 2003
Posts: 3336
Location: Oldenburg, Germany
|
| Posted: Thu Oct 23, 2003 10:07 pm Post subject: |
|
|
| mohrt wrote: | | If this last patch works ok, maybe we'll just keep what we've got. |
i hoped that, too. i don't want to be a spoiler, but:
{$foo|substr:$p+1} gives <?php echo $this->_tpl_vars['foo']+1; ?>
(it slurps the whole modifier, not very nice) |
|
| Back to top |
|
boots
Administrator
Joined: 16 Apr 2003
Posts: 5611
Location: Toronto, Canada
|
| Posted: Thu Oct 23, 2003 11:00 pm Post subject: |
|
|
| mohrt wrote: | I like the parenthesis idea, I think boots even brought that up once before. So lets look at how this might work:
{($foo+1)}
{($foo*$bar)}
{($foo->bar-$bar[1]*$baz->foo->bar()-3*7)} <-- uh oh, problem?
{if ($foo+$bar.test%$baz*134232+10+$b+10)}
{$foo|truncate:"`($fooTruncCount/$barTruncFactor-1)`"}
{assign var="foo" value="`($foo+$bar)`"}
We already allow parenthesis for objects, so I'm not sure if that's going to cause a problem with the parser or not. |
Yes, your memory serves you well--I did bring this up before  . My suggestion, though, would disallow:
{$foo|truncate:"`($fooTruncCount/$barTruncFactor-1)`"}
since the expression is contained in backticks. On the other hand,
{$foo|truncate:"`($foo->bar())`"}
would have to be allowed. hmm. Parens are nice because it is more of a refinement of existing syntax rather than new syntax altogether--but my idea was motivated to make it easier for the parser to identify an expression, not harder. Does anyone have a clever solution? Perhaps one of these?
(=expression) or =expression
The =expression is nice and simple and is feasible since expression can not contain spaces.
ps. I meant "maintainability" more in the sense that the additions that simple-math make to the parser can lead to reduced options in the future due to BC issues. Particularly since the total impact of simple-math is not yet fully understood. But I'm still +1 for keeping it in |
|
| Back to top |
|
boots
Administrator
Joined: 16 Apr 2003
Posts: 5611
Location: Toronto, Canada
|
| Posted: Thu Oct 23, 2003 11:13 pm Post subject: |
|
|
| messju wrote: | | i'm all for *allowing* parenthesis, but i don't see any advantage in *forcing* them. if the only advantage in parenthesis is a potential simplification in the underlying implementation (as a hinting for the compiler to expect math, for example) i'm against them. |
Couldn't that argument be used to disallow backticks?
| messju wrote: | to get things right (IMHO) that would mean that parenthesis not only denote expressions but also seperate sub-expressions. that would mean
{"`($a+$b)`"} but also {$foo.($bar.baz)} or maybe {$var|mod:($arg|succ)}.
i know that's not the easiest way to do this, but IMHO it's the most viable one if we occupy the "(" and ")" chars syntactically. |
+1 (or more) |
|
| Back to top |
|
andre
Smarty Pro
Joined: 23 Apr 2003
Posts: 164
Location: Karlsruhe, Germany
|
| Posted: Fri Oct 24, 2003 7:40 am Post subject: |
|
|
By reading your postings above I think a real parser will be needed for Smarty in a foreseeable future. Only a correct parsing of the smarty tags will allow correct syntax checking without making the code harder and harder to understand. I must confess I tried to understand the inner core of Smarty and I have found a lot of interessting approaches but I still have no whole image of it in mind  |
|
| Back to top |
|
Troublegum
Smarty Rookie
Joined: 07 Sep 2003
Posts: 33
Location: Germany
|
| Posted: Fri Oct 24, 2003 12:22 pm Post subject: |
|
|
@andre: one way could be to let the contents inside smarty tags be untouched by the compiler.
{$var} => <?php print($var); ?>
{$var + 1} => <?php print($var + 1); ?>
{$array[$var]} => <?php print($array[$var]); ?>
But that would mean, all template variables must be extracted to global variables (inside the function which includes the template) before the compiled template is included.
Also, the contents of the tags must be checked before. Otherwise, one could call any php-function inside smarty tags. :/
And what about modifiers?
On the other hand, that would solve some problems with the current smarty syntax. |
|
| Back to top |
|
boots
Administrator
Joined: 16 Apr 2003
Posts: 5611
Location: Toronto, Canada
|
| Posted: Fri Oct 24, 2003 7:56 pm Post subject: |
|
|
| Troublegum wrote: | | On the other hand, that would solve some problems with the current smarty syntax. |
But what about support for everything else, like modifiers, functions, objects, dot notation, (the list goes on) ? |
|
| Back to top |
|
boots
Administrator
Joined: 16 Apr 2003
Posts: 5611
Location: Toronto, Canada
|
| Posted: Fri Oct 24, 2003 8:04 pm Post subject: |
|
|
| andre wrote: | | By reading your postings above I think a real parser will be needed for Smarty in a foreseeable future. Only a correct parsing of the smarty tags will allow correct syntax checking without making the code harder and harder to understand. I must confess I tried to understand the inner core of Smarty and I have found a lot of interessting approaches but I still have no whole image of it in mind |
I tend to agree--though I think that the current implementation is good enough for what Smarty is today. I think Monte did a good job with the regexes in the last rewrite and for the most part, there is no problem, really. It is the edge cases that get people into trouble and mostly, it is for "questionable" practices. I think the rewrite could cause a lot of growing pains without a well defined payback. Particularly since it WILL be slower. On that end, I'd propose a combo php/c module solution where an optional module had c/c++ compiled versions of slower portions of the php code base much like ADODB does. Even with a rewrite, I think the scanner can still be regex based
IMHO, more interesting at this time is to continue modularizing and separating the various portions of Smarty. |
|
| Back to top |
|
Troublegum
Smarty Rookie
Joined: 07 Sep 2003
Posts: 33
Location: Germany
|
| Posted: Fri Oct 24, 2003 8:48 pm Post subject: |
|
|
| Quote: | | But what about support for everything else, like modifiers, functions, objects, dot notation, (the list goes on) ? |
I see no problems for functions, objects.
Dot notation itself is a little bit strange. The better way would be to break with the old syntax and simply allow the access to arrays through $array['key'].
The thing with modifiers could be a little bit tricky, if the old syntax is kept.
perhaps {modifier($variable)} would be easier .. |
|
| Back to top |
|
boots
Administrator
Joined: 16 Apr 2003
Posts: 5611
Location: Toronto, Canada
|
| Posted: Fri Oct 24, 2003 10:45 pm Post subject: |
|
|
| Troublegum wrote: | | Quote: | | But what about support for everything else, like modifiers, functions, objects, dot notation, (the list goes on) ? |
I see no problems for functions, objects.
Dot notation itself is a little bit strange. The better way would be to break with the old syntax and simply allow the access to arrays through $array['key'].
The thing with modifiers could be a little bit tricky, if the old syntax is kept.
perhaps {modifier($variable)} would be easier .. |
Why no problems for functions and objects (I mean registered objects)? Perhaps I don't understand your suggestion fully, but I was under the impression that you want the ... in {...} to be simple php.
Personally, I LIKE the old syntax including dot notation and modifiers. I think they make things easier for the intended audience and hide trivialities that designers shouldn't have to deal with. In fact, I detest the $a[] notation in templates--even for indexed arrays.
Anyways, I think this idea is a far too bold for the present problem regarding simple-math |
|
| Back to top |
|
messju
Administrator
Joined: 16 Apr 2003
Posts: 3336
Location: Oldenburg, Germany
|
| Posted: Sat Oct 25, 2003 10:29 pm Post subject: |
|
|
Troublegum: your suggestions fit very good to this thread
a (hopefully viable) fix for the current math-issues is on it's way.
this would mean for operator precedence in smarty (low to high):
- '|' and ':' (modifier-separators)
- '"', ''' and '`' (quoting and backticks)
- simple-math-operators
- '.', '[]' and '->' (array- and object dereferencing)
that means simple-math is allowed in backticks but modifiers are not. to me this is a logical and consistent behaviour. i don't know if smarty behaves like that under all circumstances but IMHO this is how it should be everywhere. |
|
| Back to top |
|
|
