PHP 5.2 compatibility #83

Closed
scribu opened this Issue Mar 1, 2012 · 36 comments

Comments

Projects
None yet
6 participants
@scribu
Contributor

scribu commented Mar 1, 2012

I noticed that the dev version (2.0) uses namespaces, a PHP 5.3 only feature.

Is there any particular reason why PHP 5.2 can't be supported?

For example, I will not be able to upgrade to 2.0 when it comes out, since my WordPress plugins can't assume a PHP 5.3 environment.

@scribu

This comment has been minimized.

Show comment Hide comment
@scribu

scribu Mar 1, 2012

Contributor

Some global stats (march 2012):

PHP 5.2: over 71%
PHP 5.3: under 23%

http://w3techs.com/technologies/details/pl-php/5/all

Contributor

scribu commented Mar 1, 2012

Some global stats (march 2012):

PHP 5.2: over 71%
PHP 5.3: under 23%

http://w3techs.com/technologies/details/pl-php/5/all

@bobthecow

This comment has been minimized.

Show comment Hide comment
@bobthecow

bobthecow Mar 1, 2012

Owner

A few more stats :)

  • PHP 5.3 was released 3 years ago.
  • Official support for PHP 5.2 ended nearly 2 years ago.

That said, I'm not fundamentally opposed to supporting 5.2. I was thinking it would be enough to keep the 1.x branch around for a while to support 5.2 though. Thoughts?

Owner

bobthecow commented Mar 1, 2012

A few more stats :)

  • PHP 5.3 was released 3 years ago.
  • Official support for PHP 5.2 ended nearly 2 years ago.

That said, I'm not fundamentally opposed to supporting 5.2. I was thinking it would be enough to keep the 1.x branch around for a while to support 5.2 though. Thoughts?

@scribu

This comment has been minimized.

Show comment Hide comment
@scribu

scribu Mar 1, 2012

Contributor

The 1.x branch is definitely a good idea, but if all the goodies are only in the 2.0 branch, it doesn't help much.

Contributor

scribu commented Mar 1, 2012

The 1.x branch is definitely a good idea, but if all the goodies are only in the 2.0 branch, it doesn't help much.

@bobthecow

This comment has been minimized.

Show comment Hide comment
@bobthecow

bobthecow Mar 1, 2012

Owner

I think my biggest reservation is that PEAR style namespacing rubs me wrong :)

I pushed a feature/5.2-support branch, particularly 000283e ... it's prob'ly incomplete but I don't have a 5.2 instance to test with right now. Wanna take a look?

Owner

bobthecow commented Mar 1, 2012

I think my biggest reservation is that PEAR style namespacing rubs me wrong :)

I pushed a feature/5.2-support branch, particularly 000283e ... it's prob'ly incomplete but I don't have a 5.2 instance to test with right now. Wanna take a look?

@scribu

This comment has been minimized.

Show comment Hide comment
@scribu

scribu Mar 1, 2012

Contributor

I set up a virtual machine and found a few other things that caused syntax errors: #84

Contributor

scribu commented Mar 1, 2012

I set up a virtual machine and found a few other things that caused syntax errors: #84

@bobthecow

This comment has been minimized.

Show comment Hide comment
@bobthecow

bobthecow Mar 2, 2012

Owner

One more data point: 5.4!

Owner

bobthecow commented Mar 2, 2012

One more data point: 5.4!

@rjd22

This comment has been minimized.

Show comment Hide comment
@rjd22

rjd22 Mar 15, 2012

@bobthecow I think we shouldn't neglect the 5.2 users. Most users can't update their servers because php 5.3 breaks their code.

rjd22 commented Mar 15, 2012

@bobthecow I think we shouldn't neglect the 5.2 users. Most users can't update their servers because php 5.3 breaks their code.

@bobthecow

This comment has been minimized.

Show comment Hide comment
@bobthecow

bobthecow Mar 18, 2012

Owner

Done. 2.x will support PHP 5.2+

Owner

bobthecow commented Mar 18, 2012

Done. 2.x will support PHP 5.2+

@bobthecow bobthecow closed this Mar 18, 2012

@scribu

This comment has been minimized.

Show comment Hide comment
@scribu

scribu Mar 18, 2012

Contributor

Would it be possible to rename Mustache_Mustache to just Mustache, like in 1.x ?

Contributor

scribu commented Mar 18, 2012

Would it be possible to rename Mustache_Mustache to just Mustache, like in 1.x ?

@bobthecow

This comment has been minimized.

Show comment Hide comment
@bobthecow

bobthecow Mar 18, 2012

Owner

Unfortunately not while still maintaining compatibility with PSR-0. While it allows for PHP 5.2 compatible PEAR-style class namespacing, it doesn't allow for non-namespaced "top-level" classes.

That said, there's nothing wrong with you doing use Mustach_Mustache as Mustache; (PHP 5.3) or class Mustache extends Mustache_Mustache {} (PHP 5.2).

Owner

bobthecow commented Mar 18, 2012

Unfortunately not while still maintaining compatibility with PSR-0. While it allows for PHP 5.2 compatible PEAR-style class namespacing, it doesn't allow for non-namespaced "top-level" classes.

That said, there's nothing wrong with you doing use Mustach_Mustache as Mustache; (PHP 5.3) or class Mustache extends Mustache_Mustache {} (PHP 5.2).

@ajacksified

This comment has been minimized.

Show comment Hide comment
@ajacksified

ajacksified Mar 18, 2012

Coming into this late, but my two cents:

2.x should be 5.3 only. It came out three years ago, there is no official support for 5.2. There's already a solid 1.x release available for those who cannot or wish not to upgrade. Let 2.0 be a clean, solid release with the more modern features of 5.3 (or even 5.4.)

You want to use a new library? Use a recent version of PHP.

tl;dr: support 1.x with 5.2, work on 2.x with 5.3 or 5.4.

Coming into this late, but my two cents:

2.x should be 5.3 only. It came out three years ago, there is no official support for 5.2. There's already a solid 1.x release available for those who cannot or wish not to upgrade. Let 2.0 be a clean, solid release with the more modern features of 5.3 (or even 5.4.)

You want to use a new library? Use a recent version of PHP.

tl;dr: support 1.x with 5.2, work on 2.x with 5.3 or 5.4.

@bobthecow bobthecow reopened this Mar 18, 2012

@bobthecow

This comment has been minimized.

Show comment Hide comment
@bobthecow

bobthecow Mar 18, 2012

Owner

Reopening for discussion :)

Owner

bobthecow commented Mar 18, 2012

Reopening for discussion :)

@bobthecow

This comment has been minimized.

Show comment Hide comment
@bobthecow

bobthecow Mar 18, 2012

Owner

@ajacksified I agree with your sentiment. That was my original intent for the 2.x release.

But I also see the value in compatibility: Where possible, a library should strive to be compatible. In this case, namespaces is the one compromise when making v2.x compatible with 5.2.

Thoughts?

Owner

bobthecow commented Mar 18, 2012

@ajacksified I agree with your sentiment. That was my original intent for the 2.x release.

But I also see the value in compatibility: Where possible, a library should strive to be compatible. In this case, namespaces is the one compromise when making v2.x compatible with 5.2.

Thoughts?

@scribu

This comment has been minimized.

Show comment Hide comment
@scribu

scribu Mar 18, 2012

Contributor

You want to use a new library? Use a recent version of PHP.

That is a valid argument when you are the end-user of the library, but not when you want to bundle that library within an established project, which is then distributed to end-users.

In the end, it boils down to what you value more: a cleaner codebase or broader adoption.

Contributor

scribu commented Mar 18, 2012

You want to use a new library? Use a recent version of PHP.

That is a valid argument when you are the end-user of the library, but not when you want to bundle that library within an established project, which is then distributed to end-users.

In the end, it boils down to what you value more: a cleaner codebase or broader adoption.

@ajacksified

This comment has been minimized.

Show comment Hide comment
@ajacksified

ajacksified Mar 18, 2012

Absolutely- which is covered by the 1.0 compatibility, correct?

One approach says: if the only thing we're giving up is namespacing, then perhaps 5.2 isn't really a step backwards. However, if we started 2.0 with the idea that 2.0 is 5.3+ and 1.0 is 5.2, then we won't have to make a surprise change to those already using the 2.0 release once we start wishing for 5.3/5.4 features. This approach sets the expectations up front.

Absolutely- which is covered by the 1.0 compatibility, correct?

One approach says: if the only thing we're giving up is namespacing, then perhaps 5.2 isn't really a step backwards. However, if we started 2.0 with the idea that 2.0 is 5.3+ and 1.0 is 5.2, then we won't have to make a surprise change to those already using the 2.0 release once we start wishing for 5.3/5.4 features. This approach sets the expectations up front.

@scribu

This comment has been minimized.

Show comment Hide comment
@scribu

scribu Mar 18, 2012

Contributor

Absolutely- which is covered by the 1.0 compatibility, correct?

Only partially, since the 1.0 branch doesn't have all the features that the branch 2.0 does.

mustache.php isn't (and shouldn't be) so complex that it requires sacrificing compatibility for features introduced in PHP 5.3 or 5.4, such as namespaces or traits. We're not talking about millions of LOC here.

Contributor

scribu commented Mar 18, 2012

Absolutely- which is covered by the 1.0 compatibility, correct?

Only partially, since the 1.0 branch doesn't have all the features that the branch 2.0 does.

mustache.php isn't (and shouldn't be) so complex that it requires sacrificing compatibility for features introduced in PHP 5.3 or 5.4, such as namespaces or traits. We're not talking about millions of LOC here.

@bobthecow

This comment has been minimized.

Show comment Hide comment
@bobthecow

bobthecow Mar 18, 2012

Owner

@ajacksified Twig and sfYAML's 5.2 compatibility hasn't seemed to hamper the adoption of Symfony2 and Silex.

@scribu As far as I can tell, the only new functionality in 2.x is template/partial autoloading, helpers and compiling. Template compiling is an implementation detail, but the other two are definitely beneficial features. Would backporting autoloading and helpers to 1.x be enough to keep them at feature parity?

Owner

bobthecow commented Mar 18, 2012

@ajacksified Twig and sfYAML's 5.2 compatibility hasn't seemed to hamper the adoption of Symfony2 and Silex.

@scribu As far as I can tell, the only new functionality in 2.x is template/partial autoloading, helpers and compiling. Template compiling is an implementation detail, but the other two are definitely beneficial features. Would backporting autoloading and helpers to 1.x be enough to keep them at feature parity?

@scribu

This comment has been minimized.

Show comment Hide comment
@scribu

scribu Mar 18, 2012

Contributor

Achieving feature parity between 1.x and 2.x would definitely make this discussion moot.

Question is: wouldn't maintaining two branches be more work than having a single branch that works everywhere?

Contributor

scribu commented Mar 18, 2012

Achieving feature parity between 1.x and 2.x would definitely make this discussion moot.

Question is: wouldn't maintaining two branches be more work than having a single branch that works everywhere?

@ajacksified

This comment has been minimized.

Show comment Hide comment
@ajacksified

ajacksified Mar 18, 2012

Only partially, since the 1.0 branch doesn't have all the features that the branch 2.0 does.

No reason having separate versions means 1.x doesn't get 2.x features.

My point was that setting the expectation that 2.0 is for 5.3+ makes sense, in the event that if you did find need for 5.3/5.4 (5.5, etc) in the future, you wouldn't have to go through this again, and make either a 3.0 or a breaking change to 2.x. It seems cleaner to have a 'current' branch that works against the current version of your language (in this case, 5.4), as well as a 'compatibility' branch that works against the mainstream.

Alternatively, maybe 'master' is 5.2, and an 'experimental' that works against 5.4.

Ultimately, if there isn't anything terribly interesting in 5.4, you can figure it out when 5.5 comes around ;)

Only partially, since the 1.0 branch doesn't have all the features that the branch 2.0 does.

No reason having separate versions means 1.x doesn't get 2.x features.

My point was that setting the expectation that 2.0 is for 5.3+ makes sense, in the event that if you did find need for 5.3/5.4 (5.5, etc) in the future, you wouldn't have to go through this again, and make either a 3.0 or a breaking change to 2.x. It seems cleaner to have a 'current' branch that works against the current version of your language (in this case, 5.4), as well as a 'compatibility' branch that works against the mainstream.

Alternatively, maybe 'master' is 5.2, and an 'experimental' that works against 5.4.

Ultimately, if there isn't anything terribly interesting in 5.4, you can figure it out when 5.5 comes around ;)

@scribu

This comment has been minimized.

Show comment Hide comment
@scribu

scribu Mar 18, 2012

Contributor

Alternatively, maybe 'master' is 5.2, and an 'experimental' that works against 5.4.

That sounds like a more reasonable approach.

Just as an aside, Python 3 has a similar adoption problem, but for different reasons. Most libraries still target Python 2.7 or older.

Contributor

scribu commented Mar 18, 2012

Alternatively, maybe 'master' is 5.2, and an 'experimental' that works against 5.4.

That sounds like a more reasonable approach.

Just as an aside, Python 3 has a similar adoption problem, but for different reasons. Most libraries still target Python 2.7 or older.

@bobthecow

This comment has been minimized.

Show comment Hide comment
@bobthecow

bobthecow Mar 18, 2012

Owner

Ultimately, if there isn't anything terribly interesting in 5.4, you can figure it out when 5.5 comes around ;)

For the limited use case that is Mustache.php, it seems that the only interesting things in either 5.3 or 5.4 are namespaces and syntactic sugar. I'm a huge fan of both, but in the end, neither is enough to sway me one way or the other.

Owner

bobthecow commented Mar 18, 2012

Ultimately, if there isn't anything terribly interesting in 5.4, you can figure it out when 5.5 comes around ;)

For the limited use case that is Mustache.php, it seems that the only interesting things in either 5.3 or 5.4 are namespaces and syntactic sugar. I'm a huge fan of both, but in the end, neither is enough to sway me one way or the other.

@bobthecow

This comment has been minimized.

Show comment Hide comment
@bobthecow

bobthecow Mar 18, 2012

Owner

Question is: wouldn't maintaining two branches be more work than having a single branch that works everywhere?

At this point, no. The two new features in the 2.0-dev branch can easily be backported, and 5.2 users may continue to use v1.x until such a time as they get around to upgrading :)

That isn't to preclude future 2.x features that are only available in 5.3+... I see no reason to hold back the library to maintain compatibility. As @ajacksified points out, setting the expectation that 2.x is 5.3+ from the outset would prevent having to make breaking changes when such a new unsupportable feature comes around.

Owner

bobthecow commented Mar 18, 2012

Question is: wouldn't maintaining two branches be more work than having a single branch that works everywhere?

At this point, no. The two new features in the 2.0-dev branch can easily be backported, and 5.2 users may continue to use v1.x until such a time as they get around to upgrading :)

That isn't to preclude future 2.x features that are only available in 5.3+... I see no reason to hold back the library to maintain compatibility. As @ajacksified points out, setting the expectation that 2.x is 5.3+ from the outset would prevent having to make breaking changes when such a new unsupportable feature comes around.

@scribu

This comment has been minimized.

Show comment Hide comment
@scribu

scribu Mar 18, 2012

Contributor

That sounds a lot like premature optimisation: let's suffer now for some possible future gain.

Contributor

scribu commented Mar 18, 2012

That sounds a lot like premature optimisation: let's suffer now for some possible future gain.

@rjd22

This comment has been minimized.

Show comment Hide comment
@rjd22

rjd22 Mar 19, 2012

 It came out three years ago, there is no official support for 5.2.

I think we should stop using the age of PHP as a point since it's just not valid.

If 5.2 is blocking development of Mustache. (I think it's not) we should go with 5.3. But if you are comparing 5.2 with 5.3 you should compare it with usage not age.

It took many years to switch from 4 to 5. It will take many to switch from 5.2 to 5.3.

rjd22 commented Mar 19, 2012

 It came out three years ago, there is no official support for 5.2.

I think we should stop using the age of PHP as a point since it's just not valid.

If 5.2 is blocking development of Mustache. (I think it's not) we should go with 5.3. But if you are comparing 5.2 with 5.3 you should compare it with usage not age.

It took many years to switch from 4 to 5. It will take many to switch from 5.2 to 5.3.

@hashchange

This comment has been minimized.

Show comment Hide comment
@hashchange

hashchange Mar 20, 2012

One of the things which sets Mustache apart from other templating systems is that it works across languages. That's an important part of its appeal, certainly for me. Mustache is the idea of compatibility, taken to extremes.

To me, sacrificing compatibility within PHP, without a truly compelling reason, seems to be at odds with the philosophy behind Mustache.

One of the things which sets Mustache apart from other templating systems is that it works across languages. That's an important part of its appeal, certainly for me. Mustache is the idea of compatibility, taken to extremes.

To me, sacrificing compatibility within PHP, without a truly compelling reason, seems to be at odds with the philosophy behind Mustache.

@bobthecow

This comment has been minimized.

Show comment Hide comment
@bobthecow

bobthecow Mar 20, 2012

Owner

But 1.x does (and always will) support older versions of PHP. The question is whether new code should target a version of the language for which support was dropped nearly two years ago :)

Owner

bobthecow commented Mar 20, 2012

But 1.x does (and always will) support older versions of PHP. The question is whether new code should target a version of the language for which support was dropped nearly two years ago :)

@hashchange

This comment has been minimized.

Show comment Hide comment
@hashchange

hashchange Mar 20, 2012

I'd rephrase it slightly: The question is whether new code should target a version of the language which is by far the most widespread ;)

What I took away from the discussion above is that 5.3 gives you namespaces and some syntactic sugar. Is that enough to sacrifice compatibility with, let's face it, the mainstream?

I'd rephrase it slightly: The question is whether new code should target a version of the language which is by far the most widespread ;)

What I took away from the discussion above is that 5.3 gives you namespaces and some syntactic sugar. Is that enough to sacrifice compatibility with, let's face it, the mainstream?

@popthestack

This comment has been minimized.

Show comment Hide comment
@popthestack

popthestack Mar 20, 2012

As long as 1.x remains compatible with older versions of PHP and the maintenance that it will require doesn't become too much of a burden, I'm all for making the break now.

I'm stuck on PHP 5.2 at work and, having taken the time to back-port newer, 5.3-only libraries, I fully admit I'd rather have someone else do this work for me. But I don't expect it. I'd rather see interesting projects move forward and have the opportunity to grow in ways that wouldn't be possible on older versions of PHP than see them stagnate for the sake of compatibility.

As long as 1.x remains compatible with older versions of PHP and the maintenance that it will require doesn't become too much of a burden, I'm all for making the break now.

I'm stuck on PHP 5.2 at work and, having taken the time to back-port newer, 5.3-only libraries, I fully admit I'd rather have someone else do this work for me. But I don't expect it. I'd rather see interesting projects move forward and have the opportunity to grow in ways that wouldn't be possible on older versions of PHP than see them stagnate for the sake of compatibility.

@hashchange

This comment has been minimized.

Show comment Hide comment
@hashchange

hashchange Mar 20, 2012

I absolutely agree with you, Ryan, on the premise that 5.2 compatibility should not hold a project back, and if switching to 5.3 helps to implement new stuff which wouldn't happen otherwise, then I'm all for it.

But it seems that the benefit is rather limited. Using the new (cough) 5.3-only features is not a good thing in and of itself. There is a tradeoff involved, and from what I read here, it seems that breaking compatibility does not bring about any concrete, identifiable features, nor any other substantial advantages for that matter. Or does it?

I absolutely agree with you, Ryan, on the premise that 5.2 compatibility should not hold a project back, and if switching to 5.3 helps to implement new stuff which wouldn't happen otherwise, then I'm all for it.

But it seems that the benefit is rather limited. Using the new (cough) 5.3-only features is not a good thing in and of itself. There is a tradeoff involved, and from what I read here, it seems that breaking compatibility does not bring about any concrete, identifiable features, nor any other substantial advantages for that matter. Or does it?

@ajacksified

This comment has been minimized.

Show comment Hide comment
@ajacksified

ajacksified Mar 22, 2012

Having said my piece and thinking about it for a few days, perhaps 2.0 should indeed roll out as 5.2-compatible, with an experimental branch that potentially breaks compatibility with versions behind the latest (being 5.4).

When 2.0 starts dragging at the expense of not using the latest, re-visit, and put out a 3.0 and make 2.0 legacy.

Personally, I'll be using experimental. Live on the wild side. :shipit:

Having said my piece and thinking about it for a few days, perhaps 2.0 should indeed roll out as 5.2-compatible, with an experimental branch that potentially breaks compatibility with versions behind the latest (being 5.4).

When 2.0 starts dragging at the expense of not using the latest, re-visit, and put out a 3.0 and make 2.0 legacy.

Personally, I'll be using experimental. Live on the wild side. :shipit:

@bobthecow

This comment has been minimized.

Show comment Hide comment
@bobthecow

bobthecow Mar 24, 2012

Owner

@ajacksified I'm leaning toward the same.

I do hate Mustache_Mustache very much though. Anyone have clever ideas for what to call that class instead? Mustache_Engine?

Owner

bobthecow commented Mar 24, 2012

@ajacksified I'm leaning toward the same.

I do hate Mustache_Mustache very much though. Anyone have clever ideas for what to call that class instead? Mustache_Engine?

@rjd22

This comment has been minimized.

Show comment Hide comment
@rjd22

rjd22 Mar 26, 2012

@bobthecow use Mustache_Core

rjd22 commented Mar 26, 2012

@bobthecow use Mustache_Core

@hashchange

This comment has been minimized.

Show comment Hide comment
@hashchange

hashchange Mar 26, 2012

Glad to see you consider 5.2 support :)

I'd probably go with Mustache_Engine because I'd want it to signal at first glance where the public API is located - engine is a bit better than core in that regard IMO. But one can always RTFM of course, so the difference is not really important.

Glad to see you consider 5.2 support :)

I'd probably go with Mustache_Engine because I'd want it to signal at first glance where the public API is located - engine is a bit better than core in that regard IMO. But one can always RTFM of course, so the difference is not really important.

@bobthecow

This comment has been minimized.

Show comment Hide comment
@bobthecow

bobthecow May 2, 2012

Owner

In the most common context this class will be used, I feel like Mustache_Engine captures the meaning a bit better than Mustache_Core or Mustache_Environment or any of the dumb ideas I came up with:

<?php
$m = new Mustache_Engine;
echo $m->render('Hello {{planet}}', array('planet' => 'World!')); // "Hello World!"

With this change, Mustache.php v2.0-dev has full PHP 5.2 support, and doesn't have a dumb name for its most commonly referenced class. I'd say it's time to close this issue :)

Owner

bobthecow commented May 2, 2012

In the most common context this class will be used, I feel like Mustache_Engine captures the meaning a bit better than Mustache_Core or Mustache_Environment or any of the dumb ideas I came up with:

<?php
$m = new Mustache_Engine;
echo $m->render('Hello {{planet}}', array('planet' => 'World!')); // "Hello World!"

With this change, Mustache.php v2.0-dev has full PHP 5.2 support, and doesn't have a dumb name for its most commonly referenced class. I'd say it's time to close this issue :)

@bobthecow bobthecow closed this May 2, 2012

@ajacksified

This comment has been minimized.

Show comment Hide comment
@ajacksified

ajacksified May 2, 2012

👍

👍

@rjd22

This comment has been minimized.

Show comment Hide comment
@rjd22

rjd22 May 9, 2012

👍

rjd22 commented May 9, 2012

👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment