date:20130128

Re: [PHP-DEV] Voting periods

2013-01-28 Thread Ryan McCue

Larry Garfield wrote:
> It's great to hear you say that, given that the messaging coming out of
> WP at the time was rather hostile. :-)

As I noted, the dynamics have changed significantly. I'd say that core
committer team as a whole is now much less conservative than before,
although they're still just as dedicated to internal backwards
compatibility.

As an example, it's looking like PDO is almost a certainty for 3.6. It
will mean some backwards compatibility issues though, so a while ago,
this wouldn't have even been considered.

(Note: I'm not a core committer, mainly due to never having the time to
commit to it, but I am heavily involved in WP development. I'm also
single-handedly responsible for ~10% of the codebase via SimplePie.)

> I don't know much if anything about WP internals, but in my experience
> with Drupal 8 LSB is about the only 5.3 feature that hasn't mattered to
> us.  Namespaces/PSR-0 and closures have been very helpful.  LSB not so
> much, but then I'm pleased to say we have very little static method use
> in the first place.

Namespaces don't matter to WordPress really, since it'd only be new code
using them anyway. Changing existing class names would be a huge
internal backwards compatibility break which I doubt will ever happen.

Closures, as I mentioned, don't work well with our action/filter system.
Basically, in order to be able to unregister a callback, you need to
pass in the exact callback that you registered it with; with closures,
this isn't possible unless they're assigned to a variable, which defeats
the purpose.

> Maybe next year it will be time for a GoPHP5.5 project. :-) Hopefully by
> then WP will have become less conservative enough to join the effort.

Here's hoping. :)

-- 
Ryan McCue

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Voting periods

2013-01-28 Thread Larry Garfield


On 01/29/2013 01:30 AM, Ryan McCue wrote:

If Wordpress announced that it was going to start requiring PHP 5.3 as
of some date 6+ months in the future (and there are advantages to doing
so that don't require major BC breaking rewrites), I think you'd see a
rather significant abandonment of PHP 5.2 among hosts. Many other major
projects already have.  I would be rather surprised if Drupal 9 doesn't
require PHP 5.4.  (Drupal 8, currently in development, is very solidly
PHP 5.3.)

Here's hoping that Drupal can lead that push with the major hosts. 5.2
on 66% of hosts is ridiculous, and I'm personally sick of having to
backport things to 5.2. GoPHP5 was a *fantastic* effort and benefited WP
immensely even if we weren't directly involved.


It's great to hear you say that, given that the messaging coming out of 
WP at the time was rather hostile. :-)



Most of the WordPress committers don't see much advantage with pushing
to 5.3 though, so it's doubtful that we'll lead that charge. (Late
static binding is probably the only thing that they would see as useful,
but WP doesn't use many static methods.)


I don't know much if anything about WP internals, but in my experience 
with Drupal 8 LSB is about the only 5.3 feature that hasn't mattered to 
us.  Namespaces/PSR-0 and closures have been very helpful.  LSB not so 
much, but then I'm pleased to say we have very little static method use 
in the first place.



This all said, the internal dynamics of the WordPress core developers
are always changing, and views are definitely becoming less
conservative. I don't think you'll see us targeting 5.4 any time soon,
but 5.3 is a possibility. I've been talking to a few contacts from the
big hosts in the WP space and it seems like they've all got 5.3
upgrading in the pipeline.


Maybe next year it will be time for a GoPHP5.5 project. :-) Hopefully by 
then WP will have become less conservative enough to join the effort.


--Larry Garfield

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Voting periods

2013-01-28 Thread Ryan McCue

Larry Garfield wrote:
> Hi Ryan.  While I understand that level of conservatism, I think it is
> somewhat unfounded.  The PHP community at large decided to deprecate PHP
> 4 en masse, and put hosts on notice.  It worked, too. The GoPHP5 project
> included over 100 projects and 200 hosts that collectively decided it
> was time to kill off PHP 4 and move to PHP 5.2.  That launched before
> the PHP Internals team decided to deprecate PHP 4 [1] , and had been in
> the works for a few months prior.  And that was even without the support
> of heavyweight Wordpress.

I agree completely personally, I think we need to push much harder for
it and that it would be possible to hit 5.4 by the end of the year.

I was however stating the WordPress party line which is that we don't
need 5.3+ and that we'll only push if we need to. I think it's a shame
personally, but that's what has been decided.

(In my own projects, I target 5.3+ for most projects, but 5.2+ for
projects which need wide deployment, such as SimplePie and Requests.)

> If Wordpress announced that it was going to start requiring PHP 5.3 as
> of some date 6+ months in the future (and there are advantages to doing
> so that don't require major BC breaking rewrites), I think you'd see a
> rather significant abandonment of PHP 5.2 among hosts. Many other major
> projects already have.  I would be rather surprised if Drupal 9 doesn't
> require PHP 5.4.  (Drupal 8, currently in development, is very solidly
> PHP 5.3.)

Here's hoping that Drupal can lead that push with the major hosts. 5.2
on 66% of hosts is ridiculous, and I'm personally sick of having to
backport things to 5.2. GoPHP5 was a *fantastic* effort and benefited WP
immensely even if we weren't directly involved.

Most of the WordPress committers don't see much advantage with pushing
to 5.3 though, so it's doubtful that we'll lead that charge. (Late
static binding is probably the only thing that they would see as useful,
but WP doesn't use many static methods.)

This all said, the internal dynamics of the WordPress core developers
are always changing, and views are definitely becoming less
conservative. I don't think you'll see us targeting 5.4 any time soon,
but 5.3 is a possibility. I've been talking to a few contacts from the
big hosts in the WP space and it seems like they've all got 5.3
upgrading in the pipeline.

-- 
Ryan McCue

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Voting periods

2013-01-28 Thread Larry Garfield


On 01/28/2013 08:54 PM, Ryan McCue wrote:

Zeev Suraski wrote:

The vast majority of the PHP community is a silent one;  These people
don't participate here on internals;  They don't attend conferences;  They
use it - the vast majority of them in a professional manner - and they
picked it because they like it the way it is, not because of what it needs
to become.  For every person that subscribes to internals, there's a
thousand (yes, a THOUSAND) people who don't (it's several thousands vs.~5
million).  In fact, they're not completely silent.  They speak in volumes
- PHP 5.4 is used in less than 1% of the sites using PHP today, and even
the relatively revolutionary 5.3 is still a lot less popular than 5.2.
The new shiny features are not all that interesting for most people.

I'd like to speak to this as someone involved in WordPress development.
As a whole, despite being a huge project with large amounts of
developers and users, WordPress is pretty under-represented on
php-internals.

One of the big reasons for that is that we're stuck with a lot of
backwards compatibility, both internal and external. We try hard to
ensure that our API to our plugins doesn't break, which unfortunately
has left us with being the go-to project for pointing out bad code. As
much as some may want us to, we're not going to go and rewrite WP in a
day to use new features, so internals discussions aren't that important
at the moment.

We're also stuck with a huge number of hosts still on PHP 5.2:
http://wordpress.org/about/stats/

I'd say it's somewhat of a chicken-and-egg problem, in that WP can't
develop for what's not there, and hosts won't bother upgrading if they
don't have to. We only stopped supporting PHP 4.x when the usage dropped
below 10%, and I'd see the same occurring for 5.2.

Hi Ryan.  While I understand that level of conservatism, I think it is 
somewhat unfounded.  The PHP community at large decided to deprecate PHP 
4 en masse, and put hosts on notice.  It worked, too. The GoPHP5 project 
included over 100 projects and 200 hosts that collectively decided it 
was time to kill off PHP 4 and move to PHP 5.2.  That launched before 
the PHP Internals team decided to deprecate PHP 4 [1] , and had been in 
the works for a few months prior.  And that was even without the support 
of heavyweight Wordpress.


If Wordpress announced that it was going to start requiring PHP 5.3 as 
of some date 6+ months in the future (and there are advantages to doing 
so that don't require major BC breaking rewrites), I think you'd see a 
rather significant abandonment of PHP 5.2 among hosts. Many other major 
projects already have.  I would be rather surprised if Drupal 9 doesn't 
require PHP 5.4.  (Drupal 8, currently in development, is very solidly 
PHP 5.3.)


My point being, the chicken-and-egg problem IS resolvable.  PHP userland 
developers do have that power if wielded correctly.  We just need to 
wield it together.  We shouldn't let ourselves be pushed around by 
cheapskate fly-by-night hosts again.


Disclaimer: Yes, I was the lead organizer of GoPHP5, but not the sole 
supporter.


[1] Internals started discussing killing off PHP 4 about a week after 
GoPHP5 launched back in 2007.  Whether it was entirely coincidental or 
there was some causal relationship there is, I suppose, a mystery for 
the ages.


--Larry Garfield

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Deprecate and remove calls from incompatible context (example of real usage that will break)

2013-01-28 Thread Stas Malyshev

Hi!

> I've used this in other places, it's basically lightweight traits, and 
> has always been perfectly valid code. There does not seem to be a clear 
> justification for deprecating it other than, It's not the way 'some' 
> people like code to work...

Well, I think the reason is that this code is unsafe and goes against
the principles of OO. I understand that there's a tendency to use OO as
a neat way to namespace global functions and autoload them, but that's
not how it is supposed to work.

If addPreserveText() uses anything from Footer, it should not be called
from TextRun, but if it does not, it should be in Section. I certainly
disagree that the code that calls method of Footer from TextRun is "easy
to follow" - I'd be very surprised seeing such code and would
immediately think it's some kind of bad copy-paste from one class to
another. I understand that this hack works for you - but language
usually enforce some rules of what you can and can not do, according to
some guiding principles. Having this hack goes again those principles.
As far as I know, no OO languages allow to do such things.

I note that we have people here constantly criticizing us for not
changing the names of all functions in order to satisfy their esthetic
sense, but once we change something that obviously for nearly everybody
(see vote) shouldn't even be there and never was intended to work this
way - we get criticized again for breaking stuff :)
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Voting periods

2013-01-28 Thread Stas Malyshev

Hi!

> ago I was once again confronted with errors under PHP 5.4. The module,
> responsible for the error: Content Access.
> http://drupal.org/node/1533186

I see there: Notice: Array to string conversion in
form_process_checkbox(). This means the module has a bug, and pretty bad
one at that, array-to-string is practically never intended and usually
leads to embarrassing results (I have seen one popular online newspaper
publish a column signed as "Array". True story). So it's not situation
of "works fine with 5.3 and breaks with 5.4", it's the situation "broken
in both 5.3 and 5.4, but only in 5.4 you actually know about it".

> I really appreciate all the work that is put into PHP by internals, but
> please keep in mind that the vast majority of users is covered by
> frameworks like Wordpress, Joomla, Drupal et cetera. And especially the
> frameworks with lots of user-contributed extensions, plugins or modules
> are bound to be lagging years behind PHP core development.

If you are running buggy module author of which doesn't bother to test
with recent PHP versions (or, for that matter, to do proper unit testing
which would have discovered this problem earlier) - isn't it a little
risky?
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Voting periods

2013-01-28 Thread Pierre Joye

hi Jan,

On Tue, Jan 29, 2013 at 3:50 AM, Jan Ehrhardt  wrote:

> De spijker op z'n kop, as the saying over here in Amsterdam is. There
> are two reasons why I try to change to PHP 5.4 once in a while:
> 1. In my testing it is a little bit (10%) faster than PHP 5.3.
> 2. PHP 5.3 will be out of support (even security related) much too soon.
> Every time I try to upgrade to 5.4, I have to revert it because I run
> into another drupal module that is not yet adapted to PHP 5.4. Two weeks
> ago I was once again confronted with errors under PHP 5.4. The module,
> responsible for the error: Content Access.
> http://drupal.org/node/1533186

This is one of the reason why the 'new' release process RFC does not
allow BC breaks. But we can't be 100% sure that we do not introduce
one without you, all projects and users, doing intensive testing using
your apps, modules, plugins, etc. And before the final releases, not
after.

Question: Did you test D7/8 and their respective plugins with php 5.5?

> Zeev Suraski in php.internals (Mon, 28 Jan 2013 19:22:38 +0200):

I wrote that, please either reply to one mail at a time or keep the context :)

>>I think many of us are purely and simply totally out of sync with our
>>users. I have no immediate solution but this is something we must solve,
>>now.

> Sadly enough, but true. Just read the comments by Thomas Bley, Florin
> Patan and even Lester Caine in this thread. I was really appalled by the
> outcome of the PHP 5.3 end-of-life vote. Reality check: Drupal6 is not
> and probably never will be running smoothly under PHP 5.4. Drupal7 is
> behaving better, but if somebody asks me what would be the best choice
> for Drupal7 at the moment I'll advise PHP 5.3 without any hesitation.
> Only concern: PHP 5.3 will be without security updates within a year and
> some months.

There is nothing we can do about that. Also we work closer with
distributions to be sure that we are all in sync. Distributions will
backport security fixes for a longer period.

We can't afford to support many branches for 5-8 years per branch.
That's simply not possible with our resources. However it would be
nice that you keep in mind what we have done in the last couple of
years, to reduce the wtf factors on update, to do more bugs fixes
releases, fixed release cycle, BC policy, fixed life cycle. I am very
confident that all these changes help to reduce the delay to migrate
to newer versions, given that the main reason users (ISP or
developers) do not update are BC issues. But that is not something we
can achieve without projects support, projects like Drupal or WP.
Increasing the recommended version to run your current stable releases
help, a lot, instead of keep recommending 5.2 or even lower for some
other projects.

This is a dual side problem, one cannot blame only php.net for not
doing the right things. We did mistakes, we learned from them and we
changed drastically the way we work, the way we move forward.

> Another point of view for US-citizens: many of our sites deal with
> patient information and therefore we are bound by HIPAA-restrictions.
> Quote from
> http://www.hhs.gov/ocr/privacy/hipaa/understanding/srsummary.html
>
> |Transmission Security. A covered entity must implement technical
> |security measures that guard against unauthorized access to e-PHI
> |that is being transmitted over an electronic network
>
> Running those sites on a PHP version without security updates is
> out-of-the-question.

Distros offer extended long term support for this exact purpose (not
specific to US). That's not something we can support, unless we create
an org with full time employees doing only support.

Cheers,
--
Pierre

@pierrejoye

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Deprecate and remove calls from incompatible context (example of real usage that will break)

2013-01-28 Thread Alan Knowles

On Monday, January 28, 2013 11:30 PM, Zeev Suraski wrote:

Alan,

Can you explain why you think it's a major BC break? The RFC suggested that
the BC break would be minimal and that the likelihood a lot of people used
it is very low. If you think differently and share it it might put it in a
different light.

Zeev
This is an example of recently written code that from my understanding
will now generate a E_DEPRECATED based on that RFC

http://git.roojs.org/?p=pear;a=blob;f=Document/Word/Writer/Section/TextRun.php;hb=HEAD#l136

The concept there is
Class ... Section

Class ...Section_Footer extends ...Section

Class ...Section_TextRun extends ..Section

The method 'addPreserveText' is in Footer, however the method is needed
in TextRun, so It's called statically (expecting $this to be similar, as
the both extend the same base class).

Yes, this could be fixed other ways (putting addPreserveText to
'Section') or a Trait,

however the current method has a number of benefits
a) the code is easy to follow - hence we can get anyone to understand
it quickly.
b) putting it in the parent class would expose it to the children (where
it may not be valid)
c) traits would add a little extra complexity, and make the code a
little bit more difficult to follow.

I've used this in other places, it's basically lightweight traits, and
has always been perfectly valid code. There does not seem to be a clear
justification for deprecating it other than, It's not the way 'some'
people like code to work...

94 matches

Mail list logo