Re: [SMARTY-DEV] objects: one more approach

On Thu, 2003-01-16 at 02:25, André Rabold wrote: > Hello, > > I tend to use the first syntax $foo->bar("foo", "bar"). You could > register > objects using > $smarty->register_object('foo', array('bar','blah')); > So we know the first argument of foo is"bar", the second is "blah" > now both {$foo->bar bar="1" blah="2"} and > {$foo->bar blah="2" bar="1"}work well. The method call is always > $foo->bar("1","2"). > Or am I wrong? I don't think we need to register the order of parameters. We just need to support both mechanisms. If the object takes the arguments as one parameter then the order does not matter. If it takes the arguments as individual parameters then the order DOES matter. It is just a matter of figuring out how to handle both. I'm thinking of leaving object registration out anyways, just avoid private functions, the rest of the security is up to the object. > > If I first need to rewrite all objects or make a wrapper method for > them why should I even use object support in Smarty? In this case I > can make just normal Smarty Function Plugins. Right, so we handle both formats of objects. The Smarty way, and the traditional way. I'm thinking a reservered parameter, see below. > > And please consider one thing: If you implement object access in > Smarty you also need to implement objects for {if}. > > I still like the very first implementation {$foo->bar(1,2,3)} the best > because it was the easiest to learn syntax for all semi-programmers. > If you combine this syntax with the $smarty->register_object() > thing it would be the most powerful solution and it would be a clear > way. Object property support was already implemented in Smarty > and I'm sure some / alot of people are already using it. So modifying > the syntax wouldn't be too good. > Once again: The next logical step would be {$foo->bar($a,$b,$c)} > syntax for me. But I know you don't like it very much. > > * Syntax is common for all semi-programmers (to develop a > template also needs some programming skills) But that's just it, we don't want to build a programming language. This is a template engine, and the template syntax should be kept to a minimum. I think it already has more than enough the way it is, and I'd like to work within the syntax we already have. The template does not care whether the underlying construct is a function, an object, etc. I'd really like to crack this issue without adding new syntax. I'd even like to get rid of the $foo->bar syntax and just use $foo.bar or something else that exists. Yes the object support was put in CVS, but not in anything released. In retrospect, I think doing this is not a good idea, and it should probably be removed. I think if we add new syntax for objects, we've started down a path that will ultimately hurt Smarty's development. I (and I think I speak for many others) don't want this to evolve into a programming language. We almost have it with this syntax: {$foo->bar p1="foo" p2="bar"} The issues at hand that I know of: * identifying the difference between properties and methods {$foo->bar p1="foo"} <--method {$foo->bar} <-- method or property? I'm not sure how to solve this yet, we probably need a way to identify this via syntax. Currently, if you pass any argument then it is treated as a method, otherwise a property. Obviously this won't work on methods with no arguments. I might just add a runtime function that determines what is being called, with methods taking presidence. * using in-line like in an IF statement or function parameter: The only solution I can think of is to assign it first. "assign" would be a reserved parameter name, much like any other Smarty function: {$foo->bar p1="foo" p2="bar" assign="blah"} {if $blah ne 2} ... {/if} * supporting existing object API Maybe another reserved parameter name: {$foo->bar p1="foo" p2 = "bar" wrapper=true} This would cause the parameter order to be important, and pass them to the object in that order. Otherwise it uses the Smarty object format. Monte