+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
>>
