Using Namespaces

[samuelwilliams]

I am really liking this library, but perhaps we can embrace namespaces instead or require statements. It will make the code a lot cleaner. We can utilise the PSR-0 standard and bundle an autoloader if required.

BTW, happy to spearhead

[richthegeek]

We have previously investigated PSR-0 and use of namespaces, but unfortunately it's a bit too new.

Namespaces are a 5.30+ feature and there are too many servers out there still running less than that. Not everyone can update their environment!

If i'm fatally misunderstanding whether using namespaces in < 5.3 is feasible, of course?

[samuelwilliams]

Fair enough if one of the goals of the project is maintain backward compatibility. In that case, we can still be PSR-0 compliant without using namespaces, we would need to utilise the PEAR naming convention; Instead of SassCompactRenderer the class name would be Sass_Renderer_Compact and would live in Sass/Renderer/Compact.php. This would be PSR-0 compliant and php 5.2 compatible.

[jmverges]

Hey mates, I think like Samuel, PSR-2 standard is good stuff.

[samuelwilliams]

I will try and put together a concept and see how that goes.

[jmverges]

Samuel, if you do a new branch I would like to contribute

[samuelwilliams]

Hi, here is a first commit with a lot of restructuring. https://github.com/samuelwilliams/phpsass/tree/psr0

[ReSpawN]

That's a pretty good restructure Samuel, looking forward to it being incorporated. Did any test performance-wise? We're running 5.3 (I believe .19) right now so we would really like to see some of those PSR-2 standard features.

[jmverges]

Hey, Samuel, I will try to fork this branch in a few hours and maybe contribute. Good job mate!

[richthegeek]

Wow you guys were busy last night! The PSR stuff looks pretty good so far, can't wait for the pull request.

[c33s]

Namespaces are a 5.30+ feature and there are too many servers out there still running less than that.

i am also a person who likes backwards compatibility, because i like to use debian stable as server os. debian often has quite old packages in its repo, not living on the bleeding edge but on stability.

the current stable version of debian is 6.x (squeeze) which ships with php 5.3, also dotdeb has a precompiled package for php 5.4.

so why stick with lower versions?

Not everyone can update their environment! but the people really should. old environments are much slower and have no security updates any more. debian lenny is not maintained any more (since 2012-02-06 see https://en.wikipedia.org/wiki/Debian) and on php.net only php 5.3 and php 5.4 are available for download (see https://en.wikipedia.org/wiki/Php php 5.3 is out since 2009 and the last supported release was on 2011-01-06).

is it really a good option to be backwards compatible and "support" slower & less secure php environments and thereby also block innovation and make development more complicated? (namespaces allowing a real flexible usage of a class and also i think it helps with better developing the class itself)

sometimes its time to just move on.

comming from symfony2 i really prefer namespaces, it really helps a lot.

to cut a long story short: +1 for namespaces.

[samuelwilliams]

I don't think it is necessarily a good idea to maintain backward support for PHP 5.2 because it holds developers back. PHP 5.2 is now old-hat and is no longer supported by the PHP core team. From a corporate perspective, it is not a wise idea to maintain infrastructure that is no longer within support period. I think tough love is the way to go with these sorts of projects.

Having said that... I do not own this project and if there is strong will from the maintainers to support 5.2, then I am more than happy to back that (at least for now since I am new in this community). I think it is just as important, if not more so, to be compliant with standards that are set by PHP community leaders such as the developers of Zend, Symfony, Drupal, PHPBB among many others. Compliance with PSR 0-2 is currently achievable while maintaining backward compatibility with 5.2

And in short +1 for namespaces but so long as the core developers are happy to. Perhaps there should be an agreed version road map.

[richthegeek]

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

Until these numbers change, I'm not willing to potentially drop support for 50%+ of sites.

The transition period for PHP has always been slow (shared hosts etc), but one of the reasons people use PHPSass over Ruby is because of the same environmental restraints that stop them upgrading PHP.

I'm happy to refactor towards PSR-2, but the namespaces are not a good idea yet.

[samuelwilliams]

Happy to comply, as I said, it's not my project. Perhaps though a version roadmap should be drawn up showing when the project can move away from 5.2.

[Faryshta]

There can also be a PSR or PHP5.3 dedicated branch for those who can use it.

PHP 5.3 comes with too many new features, most of them will be better to implement slowly so its better to have a new branch for that.

[richthegeek]

I'm not sure how well doing it in a branch would work; changes provided to the master branch would be need to mirrored into the PSR branch, and the amount of refactoring involved means that it'd likely not be possible automatically.

Given that Drupal 8 and Symfony both require PHP5.3+ (and thus namespaces) means it hopefully won't be too long before dropping support for 5.2 is feasible.

Drupal 8's release is earmarked for late 2013 so at the earliest it'll be another year yet. That said, I'm not sure how many existing projects will suddenly switch to using PHPSass. It's more something that new projects use.

It'd be nice if there were numbers on what /new/ projects use, and specifically what version the users of PHPSass develop on. If the numbers are favorable within those demographics then a switch to 5.3 and namespaces would be possible.

[Faryshta]

changes provided to the master branch would be need to mirrored into the PSR branch

That can be do that with the git merge command.

hopefully won't be too long before dropping support for 5.2 is feasible.

Which is why I think having a php5.3 branch would be a good idea to start making the changes slowly

[richthegeek]

Git merge is neither infallible nor omnipotent. Whoever maintains the 5.3 branch will need to make sure that all changes are tracked quickly.

If we can get an unbiased sample of versions that PHPSass runs on then we can be better informed. Any ideas in that respect?

[Faryshta]

I volunteer :smile: to help with the 5.3 branch.

I don't get your last question.

[richthegeek]

As mentioned previously, the number of projects using 5.2 is over 50% of all sites. However, that includes legacy projects and so on.

The important metric, and the one we don't have access to, is how many projects that use PHPSass use versions that don't support namespaces. If we are dropping support for 50%+ of existing users by this switch, that's quite different to if we are only dropping support for 5%.

So as I say, we need some metrics for the intersect of "Uses PHPSass" and "Uses PHP5.3 or better"

[Faryshta]

@richthegeek ok I undestand that.

But creating a php5.3 branch won't affect those users. We can have the best of both worlds. The master will remain php5.2 friendly while there will be a branch with namespaces and other cool 5.3 features support.

As for he promotion. "You can also try the development PHP5.3 oriented branch on github". The master will keep php 5.2 for as far as it needs to.

[samuelwilliams]

Hi @Faryshta

In regard to your previous post, PSR does not mean PHP5.3

Namespaces are the preferred option in modern PHP projects, but the verbose PEAR convention is PSR compliant. I don't like the idea of branching the project and simultaneously developing PHP 5.2 and 5.3+ as that would get very very hairy. It is better to map out when a project can tick over support and only provide bug fixes for older platforms much like Symfony did when that launched Symfony2.

[Faryshta]

@samuelwilliams thanks.

To use namespaces we need php5.3. That is why I proposed to create another branch.

simultaneously developing PHP 5.2 and 5.3+ as that would get very very hairy

Well one will be the master branch with the official support and the other will be a development branch.

[c33s]

@richthegeek i really understand your motivation, but as you wrote above, are really 50% who are using php 5.2, using sass? - i don't think so.

sass is a quite modern way to work, i believe (got no proove on that), that most of the sites which are using php 5.2, are legacy apps which will not be touched anymore (just hoping it keeps working, but not investing anymore time and effort in developing any further) or small webpages developed by people who don't write object orientated and won't use things as less or sass, they will just use css (maybe bought from template sites).

so i think that your estimate of 5% is quite more reasonable than the 50% (maybe the percentage is even lover than 5%)

for you to find out who uses your code you can:

• start a vote
• ask on the mailinglist (is there one?)
• post the question on your webpage
• add an opt-out "anonymous use statistics" code (i don't really like sending statistics around, but if it helps evolving phpsass more quickly i vote for it)

hope you don't get me wrong, i don't want to offend you, phpsass is just such a cool project, that i would really love to use it with namespacing now, than to wait one more your to get it.

anyway: thanks for your time and effort in this project.

@samuelwilliams i forgot to add "@richthegeek" in my first post, it was clear for me, that you just respect the maintainers wish.

[jmverges]

+1 for namespaces

[Faryshta]

My proposition is this.

Create a branch to support namespaces that requires PHP5.3

That branch will be a development branch so we can slowly make the progress to namespaces and php5.3 since there are a lot of differences. To support both the production and development branches we can use the github tools like merge.

When the branch is mature enough release it.

Merge than branch with master and make it become the production branch turning the current used branch into a support branch.

Its the classic support / current / development workflow.

[richthegeek]

I'm ok with starting up a branch for namespaces and PSR (might as well do it all in one batch).

How do we get started on this? @samuelwilliams you have a branch in progress for PSR, correct? If I create a branch for this you could do a pull request into it? Or would you simply merge your changes to the branch on your remote and then regularly pull it back?

[samuelwilliams]

Well, the changes that I have made are for the PEAR convention (PHP 5.2). I would essentially need to re-rewrite what I have done to use namespaces (which isn't a problem). It may be a better approach in the longer run to look at being PSR compliant with 5.3 and just leave 5.2 how it is at the moment.

[onigoetz]

Hi, PSR-2 doesn't force you to use namespaces : https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-1-basic-coding-standard.md#3-namespace-and-class-names

and this would already help a lot with composer packages autoloading.

BTW: can you please add some git tags, that would help a lot with composer.

[samuelwilliams]

Sorry about the long absence from this thread. I have just updated the way that the tests are organised and have begun using namespaces/psr-0 on most of the classes. I have removed the redundant require_once statements in the classes. https://github.com/samuelwilliams/phpsass/tree/namespaces

I don't think it is wise anymore to support 5.2. Drupal 8 won't. 5.4 is out so it's time to move on. As testament, the travis file does not include 5.2 as a test environment.

[richthegeek]

I've had no emails from people wanting to use with old PHP versions, so I am happy to recommend that this initiative go ahead.

To support old versions of PHP I will create a new branch with the existing code, and namespace changes will be committed to master.

@samuelwilliams, how up to date is your fork and are you ok PR'ing it back into here?

[nsams]

please no Php 5.3 dependency, we are running on SLES 10 which still has 5.2