Re: [SMARTY-DEV] template param syntax

--- Luna Kid <listreader@neuropolis.org> wrote: > So, I missed to correctly explain my stance about the > issue you referred to as ordered parameter passing. Which I believe is unavoidable with the syntax proposed. As Monte previously pointed out, the experience of HTML led to XHTML which, like Smarty, requires named parameters in all cases. Consistent and precise syntax such as this has several implications that merit consideration. First, it is far easier for the parser to distinguish valid cases from invalid cases based merely on syntax. When ordering becomes important, semantics come into play. This makes more work not only for the parser, but importantly, also for the user writing the code who must remember the proper ordering sequence (semantics), and for other users reading the code who must do the same without any embedded clues. Contrast this to named parameters where no such confusion can arise and to which parameters are (more) obvious even to users who may be unfamiliar with a particular function. This may seem trivial, but the requirement for named parameters also helps authors in other ways, such as debugging. For example, there is no confusion that in {foo bar "baz"} a syntax error was made--the designer forgot the "=" and the parser can easily detect that and report the appropriate error message. This is a good thing as we are all apt to make trivial errors of this sort (well, I am). Imagine an ordered sequence as above being valid but that {foobar "baz"} is also valid. It is plain that in this scheme, a simple typo can lead to valid code which makes debugging all the harder. Back to the parser, much of the rest of your message shows the extra complications that quickly arise when considering unnamed paramters and particularly, the necessary choice of semantic rules. Again, it is not safe to assume that these choices will be obvious to users. Further, I believe that the suggestion that strings and numerics be collected separately further complicates the issue and again demonstrates the way things can get complicated. > With a very minor & compatible extension to the arg. > passing syntax, Smarty could bite quiet a huge chunk > of extra usability (and finally could even beat my > own hacky template processor, hopefully... ;) ). Well, I've never seen your template processor, but I think that even as-is, Smarty is a pretty good horse to bet on ;) Smarty doesn't demand very much formalism over what one might expect from something like HTML. The choices it makes are sensible considering the "needs of the many" while simultaneously providing a somewhat clear set of rules for the parser. All that being said, I DO see cases where something like you are suggesting would be interesting indeed. Unfortunately, I see these cases as not being appropriate for users at-large. One of the best things about Smarty has got to be its API and plugin architecture. You may want to consider writing a general function that parses items as you have indicated. It would be wise for your function to call-upon Smarty's base functionality where appropriate. This would then give you a general way to implement custom compiler plugins that followed your prescribed syntax and semantics. This would give you the best of both methods and could make for a worthy add-on if done with care. Greetings and best regards, xo boots __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/