Posted by boots on 06/18/05 01:23

--- Jochem Maas <jochem@iamjochem.com> wrote:
> boots wrote:
> > To be fair, it was never claimed that Smarty WAS PHP. The fact that
> > something is possible in PHP is no gaurantee that it will be
> > possible in Smarty; however, the fact that something ISN'T possible
> > in PHP is often indicative that it won't be doable in Smarty. Ergo
> > the PHP4 argument. The PHP5 sarcasm is rather unfair.
>
> yes but the fact that hardly anyone of the 'big' open php projects
> show any/much interest in going php5 is not exactly a come-on for the
> general public is it?

Hi.

There is much interest in going towards PHP5. Several of my client
projects have already migrated yet amazingly, this feature or lack
thereof has not detered that. As Monte said, Smarty is already largely
compatible with PHP5. Instead of trying to bolt the final pieces on to
the old codebase there are tenative plans to rewrite for PHP5 to
achieve not only compatability but also to leverage the new features.

> IMHO php5 is really so much of an improvement and it deserves more
> support so that feetdragging ISPs start to actually offer it!!!

This has nothing to do with Smarty.

> in what way does being able to write {$foo->bar()->bar()} break BC?
> maybe it's obvious but I don't see it. maybe its an implementation
> problem, (I have hacked Smarty for this very issue so I understand
> that this is not a simple issue per se!)

$foo->bar()->bar() doesn't work under PHP4 unless you use intermediates
to handle to function derefrencing.

> > candidate for a future version but at the same time, I think it
> > will promote several questionable practices for template usage
(such
> > as deeply nested hierarchies).
>
> I don't understand what you mean by 'deeply nested hierarchies' in
> this context - could you explain please?

A 'deeply nested hierarchy' is one where one must drill down several
layers to get to required attributes/properties (or even methods).
There is much debate on the merit of such designs in ANY context, but
they are particularly objectionable in my view for template users.
Template users need to know the least about application design and
structure. Their job is to match design to placeholders so that the
application can fill in the details. If it is unneccessarily difficult
for them to specificy the placeholders or if they must learn deep
issues regarding the application structure their job (and
effectiveness) is compromised. The main reason I see for this happening
is that application objects are passed wholesale into templates instead
of being decomposed into "friendlier" (ie. flatter) interfaces for the
view layer. This relates back because allowing $foo->bar()->bar() which
is nice for the application developers, doesn't really help template
folks very much. Indeed, all it seems to do is encourage application
developers to be lazy and not decompose difficult hierarchies into
simpler patterns for the template users.

I should note that $foo->bar()->bar() is a special case; AFAIK,
$foo->bar->bar is perfectly acceptable in Smarty and PHP4. So you can
actually help yourself somewhat by overriding __get on your objects so
that foo() is called when foo is requested. This has the benefit of
reducing the amount of syntax that a template user will face.

Finally, I'm not trying to suggest that $foo->bar()->bar() shouldn't
ever appear in any version of Smarty -- but I am suggesting that there
is some question as to its overall merit particularly when one looks at
how it will likely be used. Moreso, unless function derefencing is
backported to PHP4, my personal opinion is that it should not be
included in the 2.x series of Smarty.

best regards,
xo boots

[Back to original message]