Re: [SMARTY-DEV] Re: object support

From: Date: Thu, 16 Jan 2003 06:58:07 +0000
Subject: Re: [SMARTY-DEV] Re: object support
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14  Groups: php.smarty.dev 
Request: Send a blank email to php-smarty-dev+get-550@lists.php.net to get a copy of this message
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

« previous php.smarty.dev (#550) next »