Re: [SMARTY-DEV] GoPHP5

--- Mark Rogers <[email protected]> wrote:
> Sebastian Mendel wrote:
> > at least for phpMyAdmin, what i was talking about in last post, this is not
> > correct, as we not just anymore "take PHP<5.2 compatibility into account"
> > but actively remove code that was used to implement/simulate behavior from
> > PHP 5 and introduce OO functionality not supported by PHP 4
> >   
> 
> Oh OK, I misread it. Even so I agree that removing PHP4 workarounds is a
> good thing if there's a reason to do so (eg if PHP5 gives a better
> performing way to do something or a way which is otherwise more robust).
> Changing something that works for something that "should" be the same,
> for no other reason that to break PHP4 compatibility, would seem like a
> bad idea, as (unlike phpMyAdmin) Smarty does need to retain
> compatibility with templates written previously (whether for older
> versions or not, perhaps except where that compatibility is broken
> purely because of a PHP version issue). Ie if I have a site which works
> now on PHP5 and after the Smarty upgrade to the PHP5 version no longer
> works because something obscure is now done differently, then that *is*
> an issue, and changing things that work just to break PHP4 compatibility
> would be prone to breaking things in this way.

First, I appreciate the comment that people are making in this thread. In my
view, this is a worthwhile discussion and I am interested to hear what Smarty
users/devs think on this point.

I think I might be able to speak for the core Smarty devs when I say that we
have striven to support Smarty for the target group: PHP 4.0.6+. Indeed, we
have tended to favor PHP4 idioms over PHP5 idioms just for sake that we wanted
to make sure that Smarty was available to widest audience possible. As a result
of that effort, current versions of Smarty can be expected to run on *any* and
*all* PHP installations that one might find in production today. So, it seems
to me that it remains important to continue that level of support when it is
both easy to do so (which for Smarty it is) and while considering the fact that
PHP4 is still running at something like an 80% adoption rate. That said (and
considering that PHP4 will surely be put to pasture) I do agree that thinking
of the future always makes sense.

Now I'll speak only for myself. I've been running PHP5 for years. If for no
other reason, I highly recommend everyone who can to migrate to PHP5.2 as
quickly as they can; even if you don't need the extra features, the performance
improvements (Smarty performs best under PHP 5.2, IMO) make it worthwhile. I
think that if/when (more of a "when", then an "if") the Smarty 3.x branch
arrives, it can be expected to break with the old PHP4 compatibility just
because it will use PHP5+ only features. Until that happens, I see no harm
(perhaps even as I risk the very small reputation I may have) in continued
support for PHP4 users. I may be a PHP5 user myself, but I don't see why Smarty
has to renege on PHP4 support at this point. It costs us nearly nothing to
support PHP4 and PHP4 is wildly still the most popular version deployed.

Smarty has consistently been a lowest common denominator type of library --
without a compelling rewrite that takes specific advantage of new PHP features,
I see no reason to abandon that at this time. What other PHP library still runs
as well on 4.0.6 as it does on 5.2.1 and every version between? Should Smarty
2.x really demand 5.2+ when it can still easily support legacy users?

I'd be happy to hear more on this issue from any interested parties.

Best,
boots

PS. As an aside, it is my humble opinion that a rewrite of Smarty should target
PHP 5.2 as a minimum. I propose that it may even be worthwhile to wait for such
a change until PHP6 arrives so as to finally be able to uniformly support
unicode at the same time as upgrading the architecture.



 
____________________________________________________________________________________
Sucker-punch spam with award-winning protection. 
Try the free Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/features_spam.html