Re: [SMARTY-DEV] Re: object support
| From: | Bharat Mediratta | 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