Back in the spring, a group of PHP developers from several popular "pure frameworks" got together and started a PHP standards working group. Their goal was to standardize certain OO coding standards, in particular the use of namespaces, across PHP projects, even if such standards necessitated some changes in the participating projects' existing code bases. There was some fallout about the group being self-declared and trying to establish project standards by fiat, with a number of people, myself included, objecting to either the fait accomplis presentation, the details of the proposed standards, or both. Eventually the core team moved off to an invite-only list, and I largely lost track of them. Yesterday, they decided they should invite in representatives from a few other frameworks and projects, including Drupal. I discovered this when I suddenly found myself on the list and getting messages, as I'd been sitting in the pending membership queue for months. :-) So apparently I'm now the "Drupal representative". Goodie... So before I open my big mouth, to what degree are we interested in being involved, and to what degree are we willing to play by the standards this group develops? Personally, I think we should try to do so where possible. It's good for inter-operability, reduces the learning curve for PHP-knowledgeable developers coming into Drupal, and frankly a lot of these people have been working with OO PHP a lot longer than we have so there's much to be learned from them. It also means that we can begin to shift ourselves in the "right" direction for whenever we're able to drop PHP 5.2 and rely on PHP 5.3 namespaces, which will open up all sorts of new and exciting power and weirdness. However, I'm not sure that we should commit to following the developed standards, period. As of the last draft I saw, some of them would not, I think, even be compatible with a modular full-stack framework like Drupal to begin with, mostly regarding a universally-applicable autoload pattern. So I would like to go into the process with a statement of "we'll be involved in developing such standards and will adopt them wherever feasible, but we do not commit to following all standards if they are incompatible with Drupal's basic architecture." +1, -1, feedback, flames, recriminations, encouragements, death threats...? --Larry Garfield
+1 and I would expect that your input would help shape the standards so that they are compatible with our architecture as well since coding standards should be pretty agnostic to a programs architecture. Thanks for taking this on, Larry!
http://drupal.org/node/576248 contains the coding standards changes suggested for D7 (mostly because of PHP5). Between that and the handbook coding standards pages you should have all the info you need. I'd also say that "we'll participate" is about the best we can / should promise. Well-thought-out standards are good, but as always they might not apply to Drupal very well. - Ken Winters On Nov 11, 2009, at 11:29 AM, larry@garfieldtech.com wrote:
Back in the spring, a group of PHP developers from several popular "pure frameworks" got together and started a PHP standards working group. Their goal was to standardize certain OO coding standards, in particular the use of namespaces, across PHP projects, even if such standards necessitated some changes in the participating projects' existing code bases.
There was some fallout about the group being self-declared and trying to establish project standards by fiat, with a number of people, myself included, objecting to either the fait accomplis presentation, the details of the proposed standards, or both. Eventually the core team moved off to an invite-only list, and I largely lost track of them.
Yesterday, they decided they should invite in representatives from a few other frameworks and projects, including Drupal. I discovered this when I suddenly found myself on the list and getting messages, as I'd been sitting in the pending membership queue for months. :-) So apparently I'm now the "Drupal representative". Goodie...
So before I open my big mouth, to what degree are we interested in being involved, and to what degree are we willing to play by the standards this group develops?
Personally, I think we should try to do so where possible. It's good for inter-operability, reduces the learning curve for PHP- knowledgeable developers coming into Drupal, and frankly a lot of these people have been working with OO PHP a lot longer than we have so there's much to be learned from them. It also means that we can begin to shift ourselves in the "right" direction for whenever we're able to drop PHP 5.2 and rely on PHP 5.3 namespaces, which will open up all sorts of new and exciting power and weirdness.
However, I'm not sure that we should commit to following the developed standards, period. As of the last draft I saw, some of them would not, I think, even be compatible with a modular full- stack framework like Drupal to begin with, mostly regarding a universally-applicable autoload pattern.
So I would like to go into the process with a statement of "we'll be involved in developing such standards and will adopt them wherever feasible, but we do not commit to following all standards if they are incompatible with Drupal's basic architecture."
+1, -1, feedback, flames, recriminations, encouragements, death threats...?
--Larry Garfield
On Nov 11, 2009, at 11:29 AM, larry@garfieldtech.com wrote
So I would like to go into the process with a statement of "we'll be involved in developing such standards and will adopt them wherever feasible, but we do not commit to following all standards if they are incompatible with Drupal's basic architecture."
+1 here, sounds like a reasonable approach and adhering to common standards where possible is a good thing for the reasons you mentioned. Are there resources online to read up on the status quo of the conversation?
+1, -1, feedback, flames, recriminations, encouragements, death threats...?
--Larry Garfield
Alex Barth http://www.developmentseed.org/blog tel (202) 250-3633
Larry, Your approach on the matter sounds reasonable. In the abstract, as far as it meshes with the current architecture, we should try to comply in the interests of accessibility and interoperability of our codebase. That said, I have no idea what their standards actually entail. what would we be looking at in terms of code modifications to match up with these new standards? What kind of refactoring and rewriting would this take? Would this be a relatively simple job, or would we be looking at a good portion of the D8 or D9 development cycle to come to compatibility? What kind of workload will this place on the Drupal dev community? Either way, you are a good person to have in that discussion. Brian Vuyk http://www.brianvuyk.com larry@garfieldtech.com wrote:
Back in the spring, a group of PHP developers from several popular "pure frameworks" got together and started a PHP standards working group. Their goal was to standardize certain OO coding standards, in particular the use of namespaces, across PHP projects, even if such standards necessitated some changes in the participating projects' existing code bases.
There was some fallout about the group being self-declared and trying to establish project standards by fiat, with a number of people, myself included, objecting to either the fait accomplis presentation, the details of the proposed standards, or both. Eventually the core team moved off to an invite-only list, and I largely lost track of them.
Yesterday, they decided they should invite in representatives from a few other frameworks and projects, including Drupal. I discovered this when I suddenly found myself on the list and getting messages, as I'd been sitting in the pending membership queue for months. :-) So apparently I'm now the "Drupal representative". Goodie...
So before I open my big mouth, to what degree are we interested in being involved, and to what degree are we willing to play by the standards this group develops?
Personally, I think we should try to do so where possible. It's good for inter-operability, reduces the learning curve for PHP-knowledgeable developers coming into Drupal, and frankly a lot of these people have been working with OO PHP a lot longer than we have so there's much to be learned from them. It also means that we can begin to shift ourselves in the "right" direction for whenever we're able to drop PHP 5.2 and rely on PHP 5.3 namespaces, which will open up all sorts of new and exciting power and weirdness.
However, I'm not sure that we should commit to following the developed standards, period. As of the last draft I saw, some of them would not, I think, even be compatible with a modular full-stack framework like Drupal to begin with, mostly regarding a universally-applicable autoload pattern.
So I would like to go into the process with a statement of "we'll be involved in developing such standards and will adopt them wherever feasible, but we do not commit to following all standards if they are incompatible with Drupal's basic architecture."
+1, -1, feedback, flames, recriminations, encouragements, death threats...?
--Larry Garfield
The current draft is here, I think: http://groups.google.com/group/php-standards/web/final-proposal It seems to cover fewer things than they used to, but the one it does cover is the one that is least Drupal-friendly; specifically it mandates a direct Java-style mapping from namespace and class name to file name. I dislike that and find it fundamentally Drupal-incompatible, but we'll see. As for the level of workload, that depends on what the standards end up as and how much of them we decide to adopt. Some of the earlier bits (I don't know what's happened to them in the past few months), like always naming an interface *Interface, are already part of our coding standards because I started doing that for DBTNG, which became most of our OO standards. (That was coincidental at first, and later on deliberate.) There's already some exception-related changes we'll need to make to conform to our own standards, but those should be low-impact. The big impact, I think, will be related to namespaces. We're not using those yet, and can't until we require PHP 5.3. The odds of us doing that for Drupal 8 are, I think, slim. Hopefully by Drupal 9 we can do so, but that will depend on how the PHP market evolves. (I wonder if I need to start a GoPHP 5.3 project... <g>) TBD. If we know what the standard is going to be, though, we can certainly look at moving ourselves in a direction that will be easy to migrate to namespaces when we get there. I've been giving that a fair bit of thought recently (mostly relating to treating modules as a namespace, or sub-namespace), but there's no game plan there yet. If we can use the work of this group as a long-term roadmap planning tool, that would be great. Ken Winters: Yep, I'm all over that thread. ;-) ("Crell" is me.) Brian Vuyk wrote:
Larry,
Your approach on the matter sounds reasonable.
In the abstract, as far as it meshes with the current architecture, we should try to comply in the interests of accessibility and interoperability of our codebase.
That said, I have no idea what their standards actually entail. what would we be looking at in terms of code modifications to match up with these new standards? What kind of refactoring and rewriting would this take? Would this be a relatively simple job, or would we be looking at a good portion of the D8 or D9 development cycle to come to compatibility? What kind of workload will this place on the Drupal dev community?
Either way, you are a good person to have in that discussion.
Brian Vuyk http://www.brianvuyk.com
larry@garfieldtech.com wrote:
Back in the spring, a group of PHP developers from several popular "pure frameworks" got together and started a PHP standards working group. Their goal was to standardize certain OO coding standards, in particular the use of namespaces, across PHP projects, even if such standards necessitated some changes in the participating projects' existing code bases.
There was some fallout about the group being self-declared and trying to establish project standards by fiat, with a number of people, myself included, objecting to either the fait accomplis presentation, the details of the proposed standards, or both. Eventually the core team moved off to an invite-only list, and I largely lost track of them.
Yesterday, they decided they should invite in representatives from a few other frameworks and projects, including Drupal. I discovered this when I suddenly found myself on the list and getting messages, as I'd been sitting in the pending membership queue for months. :-) So apparently I'm now the "Drupal representative". Goodie...
So before I open my big mouth, to what degree are we interested in being involved, and to what degree are we willing to play by the standards this group develops?
Personally, I think we should try to do so where possible. It's good for inter-operability, reduces the learning curve for PHP-knowledgeable developers coming into Drupal, and frankly a lot of these people have been working with OO PHP a lot longer than we have so there's much to be learned from them. It also means that we can begin to shift ourselves in the "right" direction for whenever we're able to drop PHP 5.2 and rely on PHP 5.3 namespaces, which will open up all sorts of new and exciting power and weirdness.
However, I'm not sure that we should commit to following the developed standards, period. As of the last draft I saw, some of them would not, I think, even be compatible with a modular full-stack framework like Drupal to begin with, mostly regarding a universally-applicable autoload pattern.
So I would like to go into the process with a statement of "we'll be involved in developing such standards and will adopt them wherever feasible, but we do not commit to following all standards if they are incompatible with Drupal's basic architecture."
+1, -1, feedback, flames, recriminations, encouragements, death threats...?
--Larry Garfield
+1 for one or more members of the Drupal community being involved in developing these standards +1 for Larry being one of these members +1 for making a serious effort to adopt the standards that make sense for Drupal (especially for D8) +1 for not adopting the standards that don't make sense for Drupal +1 for requiring PHP 5.3 for D8 (that's obviously not a community decision yet, just me saying I'd support a GoPHP 5.3 project) +1 for using real namespaces once PHP 5.3 is a requirement, and following standards that support interoperability and prevent collision with other frameworks (it is so presumptuous of us to have global functions named url(), show(), hide(), etc., and we occasionally run into problems because of the overloading of underscores and hyphens to be pseudo-namespace delimiters and word separators). Thanks so much, Larry. I'm glad you're involved. larry@garfieldtech.com wrote:
The current draft is here, I think: http://groups.google.com/group/php-standards/web/final-proposal
It seems to cover fewer things than they used to, but the one it does cover is the one that is least Drupal-friendly; specifically it mandates a direct Java-style mapping from namespace and class name to file name. I dislike that and find it fundamentally Drupal-incompatible, but we'll see.
As for the level of workload, that depends on what the standards end up as and how much of them we decide to adopt. Some of the earlier bits (I don't know what's happened to them in the past few months), like always naming an interface *Interface, are already part of our coding standards because I started doing that for DBTNG, which became most of our OO standards. (That was coincidental at first, and later on deliberate.) There's already some exception-related changes we'll need to make to conform to our own standards, but those should be low-impact.
The big impact, I think, will be related to namespaces. We're not using those yet, and can't until we require PHP 5.3. The odds of us doing that for Drupal 8 are, I think, slim. Hopefully by Drupal 9 we can do so, but that will depend on how the PHP market evolves. (I wonder if I need to start a GoPHP 5.3 project... <g>) TBD. If we know what the standard is going to be, though, we can certainly look at moving ourselves in a direction that will be easy to migrate to namespaces when we get there. I've been giving that a fair bit of thought recently (mostly relating to treating modules as a namespace, or sub-namespace), but there's no game plan there yet. If we can use the work of this group as a long-term roadmap planning tool, that would be great.
Ken Winters: Yep, I'm all over that thread. ;-) ("Crell" is me.)
Brian Vuyk wrote:
Larry,
Your approach on the matter sounds reasonable.
In the abstract, as far as it meshes with the current architecture, we should try to comply in the interests of accessibility and interoperability of our codebase.
That said, I have no idea what their standards actually entail. what would we be looking at in terms of code modifications to match up with these new standards? What kind of refactoring and rewriting would this take? Would this be a relatively simple job, or would we be looking at a good portion of the D8 or D9 development cycle to come to compatibility? What kind of workload will this place on the Drupal dev community?
Either way, you are a good person to have in that discussion.
Brian Vuyk http://www.brianvuyk.com
larry@garfieldtech.com wrote:
Back in the spring, a group of PHP developers from several popular "pure frameworks" got together and started a PHP standards working group. Their goal was to standardize certain OO coding standards, in particular the use of namespaces, across PHP projects, even if such standards necessitated some changes in the participating projects' existing code bases.
There was some fallout about the group being self-declared and trying to establish project standards by fiat, with a number of people, myself included, objecting to either the fait accomplis presentation, the details of the proposed standards, or both. Eventually the core team moved off to an invite-only list, and I largely lost track of them.
Yesterday, they decided they should invite in representatives from a few other frameworks and projects, including Drupal. I discovered this when I suddenly found myself on the list and getting messages, as I'd been sitting in the pending membership queue for months. :-) So apparently I'm now the "Drupal representative". Goodie...
So before I open my big mouth, to what degree are we interested in being involved, and to what degree are we willing to play by the standards this group develops?
Personally, I think we should try to do so where possible. It's good for inter-operability, reduces the learning curve for PHP-knowledgeable developers coming into Drupal, and frankly a lot of these people have been working with OO PHP a lot longer than we have so there's much to be learned from them. It also means that we can begin to shift ourselves in the "right" direction for whenever we're able to drop PHP 5.2 and rely on PHP 5.3 namespaces, which will open up all sorts of new and exciting power and weirdness.
However, I'm not sure that we should commit to following the developed standards, period. As of the last draft I saw, some of them would not, I think, even be compatible with a modular full-stack framework like Drupal to begin with, mostly regarding a universally-applicable autoload pattern.
So I would like to go into the process with a statement of "we'll be involved in developing such standards and will adopt them wherever feasible, but we do not commit to following all standards if they are incompatible with Drupal's basic architecture."
+1, -1, feedback, flames, recriminations, encouragements, death threats...?
--Larry Garfield
2009/11/11 Alex Bronstein <alex@craftyspace.com>
+1 for requiring PHP 5.3 for D8 (that's obviously not a community decision yet, just me saying I'd support a GoPHP 5.3 project)
-1 as it kind of involves abandoning a majority of the current user base. Let's see how the 5.2 thing is handled first - the latest RHEL release is still on 5.1.6 (with maybe patches that may or may not give it enough functionality). If RHEL 6 does not get a move on, there could be many users crying foul on the support forums, and this is with what-I-assume-is-a-special-case ultra extended 2 year development cycle for Drupal 7 instead of the previous 6 to 9 month cycles.
I agree whole heartedly with you on this. FYI: The document appears to have been removed. I'd be interested in reading it if it ever appears again. Dave On Nov 11, 2009, at 9:19 AM, larry@garfieldtech.com wrote:
It seems to cover fewer things than they used to, but the one it does cover is the one that is least Drupal-friendly; specifically it mandates a direct Java-style mapping from namespace and class name to file name. I dislike that and find it fundamentally Drupal- incompatible, but we'll see.
It got renamed. The new docs (I don't think they're set in stone yet, but I just got here) are: http://groups.google.com/group/php-standards/web/php-coding-standard http://groups.google.com/group/php-standards/web/psr-0-final-proposal Feedback, I suppose, should get filtered through me and I'll try to summarize as well as I can. It's an open-read list, though, so anyone interested can browse the archives. On Wednesday 11 November 2009 8:43:49 pm David Metzler wrote:
I agree whole heartedly with you on this.
FYI: The document appears to have been removed. I'd be interested in reading it if it ever appears again.
Dave
On Nov 11, 2009, at 9:19 AM, larry@garfieldtech.com wrote:
It seems to cover fewer things than they used to, but the one it does cover is the one that is least Drupal-friendly; specifically it mandates a direct Java-style mapping from namespace and class name to file name. I dislike that and find it fundamentally Drupal- incompatible, but we'll see.
-- Larry Garfield larry@garfieldtech.com
Thanks Larry, I don't really like the java-style mapping from namespace to filename either. Would prefer to see that not happen at all.... wonder what the chances of that are.... ABSOLUTELY do not agree with treating the _ as a directory separator. Many languages do NOT do this (FLEX, etc). Would really be a pain in moving drupal in any OO directions as well. The deep trees that are typical in java are not my friend. I'd like to be able to bundle things in flatter structures, if I can. The _ directory separator greatly impedes that effort. I also don't really like the mandate of 1 class name per file name, but I'll probably get overruled on that one, too. Thanks for taking up the cause! Dave On Nov 18, 2009, at 10:05 PM, Larry Garfield wrote:
It got renamed. The new docs (I don't think they're set in stone yet, but I just got here) are:
http://groups.google.com/group/php-standards/web/php-coding-standard http://groups.google.com/group/php-standards/web/psr-0-final-proposal
Feedback, I suppose, should get filtered through me and I'll try to summarize as well as I can. It's an open-read list, though, so anyone interested can browse the archives.
On Wednesday 11 November 2009 8:43:49 pm David Metzler wrote:
I agree whole heartedly with you on this.
FYI: The document appears to have been removed. I'd be interested in reading it if it ever appears again.
Dave
On Nov 11, 2009, at 9:19 AM, larry@garfieldtech.com wrote:
It seems to cover fewer things than they used to, but the one it does cover is the one that is least Drupal-friendly; specifically it mandates a direct Java-style mapping from namespace and class name to file name. I dislike that and find it fundamentally Drupal- incompatible, but we'll see.
-- Larry Garfield larry@garfieldtech.com
"we'll be involved in developing such standards and will adopt them wherever feasible, but we do not commit to following all standards if they are incompatible with Drupal's basic architecture."
--Larry Garfield
+1 Yes, that makes sense. I think it is what we (sometimes silently) did anyway. Some of our standards are self-made (for good reason), but there are also a couple that were directly derived from example code snippets on php.net's documentation pages. In some cases, when there was no consistent standard on php.net, we even asked them for the proper standard and to fix their docs. I'm not quite sure how they can ignore an architecture like Drupal. I'm not sure whether I know of a PHP framework/CMS that is NOT extensible and doesn't support extensions to be placed in various locations, and therefore wouldn't support this strict filepath based namespacing. Thanks for staying involved, Crell! sun
I'm going to go out on a limb and say that any framework that anybody would really care about is extensible and will support extensions in different locations. And +1 to the thing about adopting standards wherever feasible. ----- Cameron Eagans Owner, Black Storms Studios, LLC http://www.blackstormsstudios.com On Wed, Nov 11, 2009 at 12:37 PM, Daniel F. Kudwien <news@unleashedmind.com>wrote:
"we'll be involved in developing such standards and will adopt them wherever feasible, but we do not commit to following all standards if they are incompatible with Drupal's basic architecture."
--Larry Garfield
+1 Yes, that makes sense. I think it is what we (sometimes silently) did anyway. Some of our standards are self-made (for good reason), but there are also a couple that were directly derived from example code snippets on php.net's documentation pages. In some cases, when there was no consistent standard on php.net, we even asked them for the proper standard and to fix their docs.
I'm not quite sure how they can ignore an architecture like Drupal. I'm not sure whether I know of a PHP framework/CMS that is NOT extensible and doesn't support extensions to be placed in various locations, and therefore wouldn't support this strict filepath based namespacing.
Thanks for staying involved, Crell!
sun
+1 to Larry for the reasons already enumerated. The only thing I have to add that may be of value, is an observation of the past. The appearance of a standard that does not appear to (a) be in the best interests of the product, (b) best interests of the user, and/or (c) make much sense other than a standard for standard's sake, is a phenomenon that happens from time to time. It makes every bit of sense in these cases to tread lightly, and not employ the standards that fall under (a) and (b), perhaps even (c), especially if (c) looks like it could cause unwanted limitations ongoing. The warning is I've seen this done with, for example, HP clinging to HP-UX when Linux was starting to get loaded on servers, IBM with DB2, QB with XML, and I could go on for a long time. Granted, some examples are come down to Open or Proprietary, but the rationale for being one instead of the other was the same (with the addition of (d) Revenue), and usually came down to a belief that the standard would probably go nowhere, and wherever it *did* go would be outweighed by (a) and (b). The result, though, in many cases was that by the time clients started griping about the solution not meeting a standard, and by the time it became a problem for the company's marketing that could not be ignored, they were way behind the curve in terms of meeting the standard, sometimes with disastrous results (for the original product and people who had lived it, at least). So, my advice is to look at whatever standard emerges with two corrective lenses, one for near-sightedness, and one for far-, but definitely not with tunnel vision...not that you would :-) Jeff
participants (12)
-
Alex Barth -
Alex Bronstein -
Brian Vuyk -
Cameron Eagans -
Daniel F. Kudwien -
David Metzler -
Jeff Greenberg -
Ken Winters -
Larry Garfield -
larry＠garfieldtech.com
-
Naheem Zaffar -
Ryan Cross