Re: [SMARTY-DEV] Re: object support

I wasn't insinuating that a copy of the object would be registered, of course you need the original object. Here is what I had in mind: how to register --------------- $smarty->register_object('foo',$myobj, array('method1','method2')); Here is what the function declaration would look like: function register_object($name, &$obj, $methods) { ... } The reference is made in the function declaration, not when the function is called. Monte On Thu, 2003-01-16 at 00:58, Bharat Mediratta wrote: > I realize that things are possibly heading in a different direction > but I wanted to respond to Monty's comments and introduce some > useful info that we'll have to address no matter what approach > we take. > > Monty says: > > Bharat says: > > > PHP already has a concept for pairing instance and method name > > > in an array and providing that in place of a function name. > > > For example, PHP's register_shutdown_function() takes this as > > > an option. So we could have this syntax: > > > > > > $smarty->register_function('themeFoo', array(&$theme, > > > 'foo')); > > > > I don't like the idea of requiring call-time pass-by-reference, many > > installations have it disabled anyways. I'd rather use a separate > > function and do that in the declaration. > > I don't believe that this falls under call-time pass-by-reference > restriction that PHP imposes. In my dev environment, I have > call-time pass-by-reference disabled and use the above construct > without any warnings or errors. > > On the contrary, I believe that the above is a necessary construct > when you register object methods. When you register, you need to > make sure that the method is called on the *exact* object that > the user specifies, not a copy of the object. For example: > > class Theme { > var $_myFoo; > > function setFoo($newFoo) { > $this->_myFoo = $newFoo; > } > > function foo() { > return $this->_myFoo; > } > } > > If we set the value: > $theme = new Theme(); > $theme->setFoo("original"); > > Then register a copy of the instance: > $smarty->register_method('themeFoo', $theme, 'foo'); > > then change the value: > $theme->setFoo("changed"); > > Then the smarty call: > {$theme.foo} (or whatever syntax we use) > > will return the "original" value, instead of the "changed" value. > That would heavily limit the functionality of registering objects > and I don't believe it's what you intend. Passing a reference > to the object won't have this problem. > > I'm happy with giving the registration function a different name > to disambiguate it, but once it's inside a Smarty template a function > callback and a method callback should occupy the same name space. > More on that below. > > ... > > > > > *) cannot have registered functions and registered objects of > > > > the same name > > > > > > > > Not a big deal? > > > > > > In the API I suggest above, it'd be the same as if you registered > > > a function twice with a different callback each time. I assume > > > that Smarty already has a way to deal with that. > > > > I'd like to see an example of what you mean. > > Sorry I didn't make it clear. I meant that if you register > a function twice, one would overwrite the other. Eg: > > $smarty->register_function('themeFoo', 'foo'); > $smarty->register_function('themeFoo', 'bar'); > > So extending that, if we were to register a function and a method > with the same callback it should amount to the same: > > $smarty->register_function('themeFoo', 'foo'); > $smarty->register_method('themeFoo', array(&$theme, 'foo')); > > (continuing my unapproved syntax from above :-) sorry). > In the Smarty template, you'd refer to either of these > as {themeFoo} and there can be only one {themeFoo} so one > registration would overwrite the other. > > -Bharat -- Monte Ohrt <monte@ispi.net>