Re: [SMARTY-DEV] Re: object support
| From: | Bharat Mediratta | Date: | Wed, 15 Jan 2003 07:09:08 +0000 |
| Subject: | Re: [SMARTY-DEV] Re: object support | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 | Groups: | php.smarty.dev |
| Request: | Send a blank email to php-smarty-dev+get-537@lists.php.net to get a copy of this message | ||
From: "Monte Ohrt" <monte@ispi.net>
...
> With this goal in mind, Bharat's original idea is looking more
> appealing, use the same syntax as a template function. This should work
> the same regardless of PHP's OO future. Example:
...
> There is no visual distinction whether "themeFoo" is a function or an
> object, so the engine would need to decipher that.
>
> So then how do we handle these? Let's say we register it:
>
> $smarty->register_object('themeFoo', $theme, 'foo');
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'));
to register a object method callback and it would be aligned
with existing PHP methodology.
>
> concerns:
>
> *) have to register every accessible method and property separately?
>
> It would be nice to register each object once somehow. I suppose you
> could do it in one go:
It'd be nice to do that, but it's not really necessary. The
speed savings would come at the expense of making illegible
code containg long arrays as arguments. IMHO it's not worth
cluttering the API.
> *) 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.
> *) should registered objects be accessible from assigned vars?
>
> probably not (see next point)
>
> *) cannot have arrays of objects
>
> Maybe Smarty won't support arrays of objects natively, but if you
> _really_ need them, you can go ahead and assign the objects and get to
> them with a custom function (just like you can do now):
>
> {object name="foo->bar" p1="foo" p2="bar"}
Sounds like a reasonable fallback to me. It's no worse than what
we have today :-)
-Bharat