Re: [SMARTY-DEV] Re: object support (more thoughts)
| From: | Bharat Mediratta | Date: | Tue, 14 Jan 2003 04:31:16 +0000 |
| Subject: | Re: [SMARTY-DEV] Re: object support (more thoughts) | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 | Groups: | php.smarty.dev |
| Request: | Send a blank email to php-smarty-dev+get-533@lists.php.net to get a copy of this message | ||
From: "Monte Ohrt" <monte@ispi.net>
...
> So decisions:
>
> 1) register all objects, and can only access directly:
>
> {$foo->bar} <-- property
> {foo->bar p1="foo"} <-- method
>
> PROS: * syntax kept to a bare minimum
> CONS: * not as flexible can't assign arrays of objects
>
>
> 2) assign all objects, and allow access to all methods excluding private
ones:
>
> {$foo->bar}
> {$foo.bar->blah}
> {$foo[bar].foo->blah}
> {foo.bar[foo]->foo p1="foo" p2="bar"}
>
> PROS: * can assign objects or arrays of objects, more flexible
> CONS: * syntax is more complex
> * can't control individual method access
>
>
> I'm really leaning toward option #1. Is there a practical use for
> assigning arrays of objects?
I like the simplicity and control of #1, but I fear that somewhere
down the line somebody will come up with a totally valid business
reason for needing arrays of objects and then we'll be out of luck.
I think that though #2 is more complex, it is more in line with
the existing Smarty model. In the existing model, {$foo} can be
either a single value or an array of values. Now we'll just be
extending it to be an object which gives us semantic equivalence
with the PHP "mixed" type. Right?
We can still deny access to methods using the approach you outlined
above, ie if the object is registered like so:
$smarty->register_object('theme', $theme,
array('foo','bar','blah'));
then at run time we could make sure that the method being invoked
is in the list of legal methods. The main problem I see with this
approach is the issue that you raised about nested objects:
{$theme->legalMethodThatReturnsAnObject->illegalMethod}
I don't see an obvious way to prevent this from happening, except
to perhaps prevent double dereferencing. I don't believe that
this is valid PHP syntax:
$theme->legalMethod()->illegalMethod()
so theoretically we could deny that functionality in the template
engine and nobody would miss it (or at least they would already be
used to not having it :-D).
So bottom line, my vote is for #2.
-Bharat