Re: [PHP-DEV] [RFC Discussion] Typed Properties

[Adam Harvey]

On 16 March 2016 at 09:36, Phil Sturgeon  wrote:
> 3. Weak vs Strict. Right now this is entirely strict, with no
> declare() to change mode. Reasons for this vary, from various sources,
> but include "Not sure how to implement it" and "Well people should not
> be using properties as part of their public API".

As much as I didn't (and don't) particularly like the declare()
switch, it doesn't seem like a good idea to me to introduce a typing
feature a year after it that doesn't use it, but has its own mode of
operation. To me, it seems like this:

class Foo {
  public int $num;
}

(new Foo)->num = $bar;

Should behave the same as the setter equivalent does today:

class Foo {
  public $num;
  public function setNum(int $num) { $this->num = $num; }
}

(new Foo)->setNum($num);

That is: if $num either can't be coerced to an integer (in weak mode)
or isn't itself an integer (in strict mode), a TypeError should be
thrown.

We could argue about whether properties should be part of a public
API, but the reality is that a class declaring a public property
effectively is making it part of its API, whether you or I think it's
a good idea or not. :)

> We'll have a nice, orderly, constructive conversation about this RFC,
> and improve the patch as you all provide feedback.
>
> Let me know what you think folks!

The above leads into another question I'm interested in your (and
Joe's) general thoughts on: how do you think this would potentially
intersect with a property getter/setter RFC in the future? Might be
good fodder for the future scope section!

Finally, while the RFC shows invalid assignments generating fatal
errors, the patch seems like it throws TypeError exceptions instead.
Which one is the desired behaviour? (I'd prefer TypeError, personally,
for consistency with function type declarations today.)

Adam

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

Re: [PHP-DEV] [RFC] Callable constructors

[Adam Harvey]

On 25 February 2016 at 14:19, Dan Ackroyd <dan...@basereality.com> wrote:
> On 25 February 2016 at 18:16, Adam Harvey <a...@adamharvey.name> wrote:
>>
>> am I right
>> that this is equivalent to the following?
>>
>>$injector->delegate('FooInterface', function (...$args) { return new
> FooImplementation(...$args); });
>
> Nope.
>
> The vital part you missed is that with the original function, all of
> the parameters (aka dependencies of the class) can be found through
> reflection, and so can be created by the injector as needed. By using
> function (...$args){} - all of the parameter information is lost, and
> so isn't usable by an autowiring-injector.

OK, I understand that now. Thanks.

Why is having a special syntax that is considered callable and
conflates instantiation and method calls (which are ultimately
separate things) better than having the injector accept a class name
and use reflection as required to instantiate that?

>> "I only skimmed the RFC"
>
> I find this very dissapointing. Conversations are far more productive
> if people have read the whole of a proposal before deciding how they
> feel about it and giving feedback.

To be clear: I did read the entire RFC, just quickly. Since it seemed
an obvious question to me (and apparently not just me, based on
/r/php), and didn't seem to be addressed that I could see, I thought
it was better to just ask it rather than stay silent and either ask it
several days later or vote -1 without explanation.

> In particular reading the sections "Can't be used as strings in class
> properties" and "Can't be used in string based configuration" would
> give examples where the RFC is of benefit in a way that is not related
> to DIC libraries.

Honestly, I still don't find either of them particularly persuasive,
for the same reasons as the aforementioned DIC example. They're
trivially special cased without muddying instantiation and method
calls. Hence my "are there analogues for this elsewhere" question.

Adam

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

Re: [PHP-DEV] Re: [RFC] Callable constructors

[Adam Harvey]

On 25 February 2016 at 09:40, Andrea Faulds  wrote:
> Instead of changing __construct to implicitly create the object it acts on
> in certain contexts, I would suggest a simpler approach: add a magic ::new()
> static method that exists on all classes (think ::class, although that is a
> constant). Foo::new() would work identically to new Foo(), and would solve
> your use case. It would be more intuitive, I think, and it avoids the
> problems of changing __construct.

(Un?)fortunately, new() is a valid method name for userland classes in PHP 7.0.

Adam

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

Re: [PHP-DEV] [RFC] Callable constructors

[Adam Harvey]

On 25 February 2016 at 08:44, Dan Ackroyd  wrote:
> I use the Auryn* DIC library. What I've wanted to do, and should be
> able to do in my opinion, is this:
>
> $injector->delegate('FooInterface', 'FooImplementation::__construct');

I only skimmed the RFC (and am unfamiliar with Auryn beyond glancing
at its documentation for about ten seconds just now), but am I right
that this is equivalent to the following?

$injector->delegate('FooInterface', function (...$args) { return new
FooImplementation(...$args); });

If that's the case, I'm not really convinced that this is worth the
syntactic sugar. I'm also somewhat concerned about conflating
instantiation and method calls — although they both ultimately call a
method, they're not actually the same thing, since instantiating an
object does extra work at the same time. Being able to just look for
"new" in code is helpful.

Open to being convinced otherwise (examples from other languages would
be helpful), but my initial reaction isn't really positive.

Thanks,

Adam

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

Re: [PHP-DEV] Throwable and Error exceptions break existing PHP 5.x code

[Adam Harvey]

On 11 January 2016 at 06:05, Rowan Collins  wrote:
> Since set_exception_handler() is intended as a last-ditch "something's gone
> very wrong" function anyway, I think it receiving all Throwables makes
> sense, even if the BC break in your scenario is unfortunate.

Agreed entirely (as I also said last time this came up). I also don't
want a third path involving a set_throwable_handler() or similar; we
have one too many error handling paths already.

One problematic thing that we _can_ help mitigate is that the first
section of the backward incompatible changes page in the manual starts
with the changes to error and exception handling, but never mentions
this specific issue (type declarations on the exception handler
breaking). That's entirely my fault (I've mentioned it enough in
conference talks that I guess I thought I'd documented it, but
hadn't), and I'll go fix that now.

Adam

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

Re: [PHP-DEV] Re: [RFC] GitHub Pull Requests Triage Team

[Adam Harvey]

On 1 January 2016 at 12:12, Bishop Bettini  wrote:
> On Fri, Jan 1, 2016 at 2:53 PM, John Bafford  wrote:
>> I think when I brought this up before, the major open discussion point
>> before the thread died was what period of time constituted long enough for
>> closing a waiting-on-submitter PR. 2 weeks is probably too short, but it
>> seemed a reasonable minimum and something had to go into the RFC. I think 4
>> weeks is probably a better place to start.
>>
>
> Warn at 2 weeks, close at 4?  There's no real harm in closing it unmerged:
> the submitter can always resubmit.

This is a contribution from the cheap seats, since I don't have time
to actually help, but I'm not a big fan of auto-closing contributions
(at least until the branch is literally closed for bug fixes). I'm
worried that it'll send a message that we don't really care about
getting outside contributions, which is obviously not the case.

What's the argument for auto-closing? Our stable branches are actually
pretty stable, so fixes and small features aren't generally going to
have merge issues that fast.

Adam, who misses the days when he could read every new bug and comment.

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

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Adam Harvey]

On 4 January 2016 at 13:06, Anthony Ferrara  wrote:
> I have created a new RFC for the PHP Project to adopt the Contributor
> Covenant as the official Code of Conduct for the project
>
> https://wiki.php.net/rfc/adopt-code-of-conduct

I am definitely pro-this. Good thinking!

> Let me know what you think or if there are any concerns

Although it's not required by our voting process, I think it might be
a good idea to require more than a basic majority for adopting this.
It feels like something we need broad buy-in on.

Thoughts?

Adam

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

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Adam Harvey]

On 4 January 2016 at 17:34, Stanislav Malyshev  wrote:
> If we're talking about having a declaration of principles, I am not sure
> we need elaborate text to say "don't be an ass" but I don't mind having
> one in case somebody ever need explicit instructions on how exactly not
> to do that :)

One thing I really like about the covenant Anthony is proposing
(besides it being the same as the one a bunch of other projects are
using) is that it actually is pretty short, considering what it is.
The English version fits on one screen on my laptop.

It's really not much more than Wheaton's Law in a form that
(hopefully) is just detailed enough to stop someone from being able to
say "but you didn't explicitly say I couldn't abuse someone because
$X".

Adam

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

Re: [PHP-DEV] Converting an 'old' PHP 5.x extension to PHP 7

[Adam Harvey]

On 10 December 2015 at 08:51, Sjoerd Maessen  wrote:
> As a first time poster I'm very nervous but here we go!

Welcome!

> I cloned the github repo and was able to remove 1 error during the
> compilation process that had to do with ZVAL_STRING. This was an easy error
> to fix since it came down to simply removing an argument. I've read
> https://wiki.php.net/phpng-upgrading but still I feel like there should be
> more resources available after seeing the amount of extensions that are
> already successfully converted for PHP 7. For example I'm now stuck how to
> fix an error like:
>
> "error: too many arguments to function ‘zend_hash_get_current_key_ex’"

We don't really have comprehensive documentation of how internal APIs
have changed from 5 to 7. Beyond the things noted on the phpng and
phpng-upgrading pages on the wiki, the best resource is probably
lxr.php.net, where you can look up a definition on both the PHP-5.6
and PHP-7.0 branches and see how they've changed.

For the most part, extension API changes are largely around things
like removing indirection on zvals, HashTables now containing zvals
rather than void pointers, and strings being represented as
zend_string structs rather than paired char * and int pointers.

> How can I continue with making this work? Any good (up-to-date) resources?
> An IRC channel where I can help?

There is #php.pecl on efnet — it's not the highest traffic channel,
but if you're patient there'll generally be someone around who can
help.

Adam

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

Re: [PHP-DEV] PHP 7 ?! :)

[Adam Harvey]

On 3 December 2015 at 13:49, Niklas Keller  wrote:
> Yes, but it's missing an usort($releases, function($a, $b) { return
> version_compare($a["version"], $b["version]); }); ;-)

I'm *cough* sure I don't know what you're *cough* talking about...

Adam

PS: 
https://github.com/php/web-php/commit/4ec6c1f342136d95035596ecb20d49ed9b25ac0c

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

Re: [PHP-DEV] INDRECT in arrays causes count() to become unpredictable

[Adam Harvey]

On 22 November 2015 at 14:19, Rasmus Lerdorf  wrote:
> On 11/22/2015 06:18 AM, Anthony Ferrara wrote:
>> Zeev,
>>
>> On Sat, Nov 21, 2015 at 11:52 PM, Zeev Suraski  wrote:
>>>
>>> IMHO, unless we think fixing this would require breaking binary 
>>> compatibility (which I don't think is the case) - this shouldn't block 
>>> 7.0.0.  7.0.0 is a lot more about getting people to start paying attention 
>>> to 7.0 and start testing their codebase against it - finding both the 
>>> incompatibilities in their code and, undoubtedly - the bugs we failed to 
>>> find.  I wish we could say this would be the last issue we find in 7.0, but 
>>> I think we can all agree it's wishful thinking...

Sure, but not every issue is created equal. Not being able to trust
count() is pretty fundamental — sure, it's not "PHP segfaults when you
access a $_GET variable" bad, but it's still bad, and it's the kind of
bug that even reasonable unit tests might not find.

> I agree with Zeev here and I had a chat with Anatol about this tonight.
> This is a .0.0 release. Nobody is going to take a .0.0 and push it
> straight to production. And it is not going to part of any sort of LTS
> distro either. It's not like LTS distros don't pick up point releases.
> There is no way we will go 2 weeks without finding something for quite a
> while still which can drag things out indefinitely. The question is
> whether this is significant enough to postpone further. Personally I
> don't think it is. Let's get 7.0.0 out the door and get ourselves on
> track for regular point releases without any of this "perfect-release"
> stress.

I disagree completely with that. No, sensible people aren't going to
push 7.0.0 straight to production, but remember David Zuelke's e-mail
from two weeks ago about how Heroku customers with poorly chosen
version constraints might end up with it by accident. The world's not
as simple as sysadmins running "./configure && make install" any more.

As a group, we're saying that 7.0.0 is "stable". That doesn't mean
perfect, but it should mean "you can trust count()".

Here's an alternative suggestion: we've previously switched to one
week RC cycles late in the piece when trying to get major releases
stabilised and we're at the point of only fixing one or two things per
RC. That's exactly where we are now. Why don't we do that again —
release a fix for this bug as an RC 8 this week, and then do a release
on December 3 if nothing else significant comes up?

Adam

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

Re: [PHP-DEV] PHP7 / foreach / references / ugly code / discrepancy to PHP 5.6

[Adam Harvey]

Hey Nikita,

On 10 November 2015 at 11:45, Nikita Popov  wrote:
> This is a bug in PHP 5, which has been fixed in PHP 7 as a side-effect of
> other changes. The new behavior is correct. This issue is tracked at
> https://bugs.php.net/bug.php?id=70857.

Are there any other variations on what expressions this changes the
behaviour of, or is it really just ternaries? Just trying to figure
out how to document this.

Thanks,

Adam

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

Re: [PHP-DEV] [VOTE] Void Return Type RFC

[Adam Harvey]

On 29 October 2015 at 06:24, Marcio Almada  wrote:
> Welcome back, Andrea! It's great to see you contributing here again :)

+1. :)

> 1) functions declared with "void" return type will still return
> "null", so "void" is a big fat lie for PHP while "null" is currently
> accurate.

I voted -1 for the same reason. I'd be +1 on "null" as a return type,
but I'm just not comfortable implying that the function doesn't return
a value when it always will in practice.

Adam

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

Re: [PHP-DEV] Scalar type hints and scalar type name aliases cause confuson

[Adam Harvey]

(Sorry Andrea, I'm picking on your e-mail because it's easiest, but
it's a general response to the thread.)

On 13 October 2015 at 06:32, Andrea Faulds  wrote:
> e.g.
>
> $ ./sapi/cli/php -r 'function foo(): long {}'
>
> Fatal error: 'long' is not a valid type hint, use 'int' instead in
> Command line code on line 1
>
> This would completely solve the confusion issue, I think. A crystal clear
> error message.

It is a good error message, but I disagree with the premise behind it:

> As I've said in a different email, I don't like the idea of allowing the
> aliases because it'd be another set of coding style differences we don't
> need. This lets us pick one name and stick with it, without causing
> confusion.

I agree that we should do something, but I think we should alias.

We allow both "int" and "integer" in settype() and we allow it in type
casting — the two other places where a user can specify a type for
conversion. I still think it's a poor choice to not allow both in type
declarations: while I'm generally a fan of having one way to do
things, I believe that the inconsistency in the language is worse than
the potential ambiguity in style guides.

Hell, _I_ still can't remember which out of "int" and "integer" is the
right one, and I've now written a decent amount of PHP 7 code _and_
wrote half of the documentation for this.

Plus, if we error when "integer" is used, we've moved people's cheese
anyway (by disallowing the class name). Let's not compound that by
forcing them to do busywork.

Adam, who hopes that anecdote doesn't say more about his working
memory than the design of the language.

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

[PHP-DEV] Re: ABI break? (was: [PHP-CVS] com php-src: Don't inline "slow" and rarely used functions.: Zend/zend_alloc.c Zend/zend_alloc.h)

[Adam Harvey]

On 16 September 2015 at 14:36, Kalle Sommer Nielsen  wrote:
> 2015-09-16 23:31 GMT+02:00 Anatol Belski :
>> While your observation is correct, I wouldn't see the matter as an alarming 
>> issue. We're oriented to have less bugs in every next RC, thus RC2 will have 
>> had its day soon anyway. So IMHO this change is not quite nice at this 
>> stage, but still acceptable.
>
> Me neither here for the matter, I believe we had such in the past with
> other releases like in 5.3 at least I think it happened at RC stage.
> Good observation nontheless but I'd rather have extensions compiled
> for the gold release of the 7.0.0 in the end for the most possible
> stability.

Fair enough — I think we have a quorum of RMs. :)

I'm frustrated that we have a mechanism to indicate "hey, we broke
binary compatibility" and we're not going to use it when we actually
did break binary compatibility, but I accept the argument.

Thanks,

Adam

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

[PHP-DEV] ABI break? (was: [PHP-CVS] com php-src: Don't inline "slow" and rarely used functions.: Zend/zend_alloc.c Zend/zend_alloc.h)

[Adam Harvey]

On 9 September 2015 at 03:42, Dmitry Stogov  wrote:
> Commit:ac83eaef1097552065395872c69b77dcab2919b1
> Author:Dmitry Stogov  Wed, 9 Sep 2015 13:42:35 
> +0300
> Parents:   6d885e395ca33fef28c5b84b7cfd59885aaa6e2d
> Branches:  master
>
> Link:   
> http://git.php.net/?p=php-src.git;a=commitdiff;h=ac83eaef1097552065395872c69b77dcab2919b1
>
> Log:
> Don't inline "slow" and rarely used functions.

This commit appears to have broken binary compatibility for extensions
that make persistent memory allocations, since __zend_malloc is now a
real function and not inlined: such an extension compiled against
php-src after this commit can no longer be loaded into earlier builds
due to the missing __zend_malloc symbol.

Most current extensions with PHP 7 compatibility aren't affected, but
the one relatively common case where a persistent allocation occurs is
when defining classes: INIT_CLASS_ENTRY() ultimately expands to
INIT_OVERLOADED_CLASS_ENTRY_EX(), which calls zend_string_init() with
the persistent flag enabled to create the class name string.

It's awkward, since PHP 7.0 hasn't officially been released yet, but
it sucks that some extensions won't be binary compatible between RC2
and RC3 (as things stand today). Options, as I see it:

1. Revert this commit.
2. Bump the extension API number.
3. Document that binary compatibility was broken in RC3, and that we
don't guarantee binary compatibility before a stable release is made.

I personally don't think option 3 is viable (yes, it's not a stable
release, but it's still crappy — avoiding this kind of thing is _why_
we have API versioning!). Dmitry, RMs: what are your thoughts?

Adam

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

Re: [PHP-DEV] set_exception_handler catches all Throwables

[Adam Harvey]

On 19 August 2015 at 07:20, Björn Larsson bjorn.x.lars...@telia.com wrote:
 Den 2015-08-19 kl. 15:55, skrev Ryan Pallas:
 I agree with this completely. I think the point here is that
 catch(Exception $e) remains unchanged while setting a handler actually
 catches more things now. Tbh I feel like this is an oversight in
 implementing the Error/Throwable rfc and should be addressed now, otherwise
 it can't be changed until 8 if I understand correctly.

 This is also a view that I share, feels more consistent that the handler
 mimics v5 and catch(Exception $e) behaviour. Hope there can be a
 decision / consensus on this topic.

I think this is absolutely an improvement, for what it's worth.
set_exception_handler(), by definition, is a last resort handler that
should be getting used primarily for logging and cleaning up, since
execution stops once it's done.

What I don't want is another path that has to be monitored to make
sure you catch every error/exception case that terminates execution.
Two callbacks is already arguably one too many, and just excluding
non-Exception Throwable objects and letting them fall through to the
error handler feels like we did a lot of work for little practical
reward.

Adam

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

Re: [PHP-DEV] libpcre version requirements

[Adam Harvey]

On 13 August 2015 at 04:35, Christoph Becker cmbecke...@gmx.de wrote:
 On 12.08.2015 at 08:44, Anatol Belski wrote:

 [...] However look - 
 http://w3techs.com/technologies/details/os-linux/all/all . From those, 
 CentOS 5/6 releases are not even a year old and contain 6.6, 7.x but take 
 20% of all the Linux market share. Note that according to that Linux takes 
 only 35.9% of it. Now, say disregarding CentOS 5 and other rare/too old 
 platforms, the other 65% of the usages are not taken into account. So how 
 much loss on PHP7 adoption would happen, is a question. Maybe there are 
 other stats, just operating on what is available.

 On the other hand  - as with the bug #70232, is it really worth disabling 
 the whole PCRE just to be sure one bug is fixed? I would see it as not being 
 such.  It is clear, that no distro will suddenly be upgrading from say PHP 
 5.3 to PHP7 in an older branch, but keeping as much compat as possible will 
 allow third party repositories to still provide PHP7 there. This is at least 
 my reason to say the version shouldn't be raised - as it shouldn't go beyond 
 7.x at least because of CentOS 6, and then it is probably useless to do it 
 ATM. As long as it doesn't block the work towards future, at least.

 Well, then it might be best to leave the requirements as they are for
 now. :)

I'm still OK requiring 8.00 in PHP 7.0, personally — even that is
almost six years old, and users on older distros and OSes can use the
bundled libpcre. It's not like this is going to break the common case
where the user doesn't set any specific PCRE flags in configure, and I
don't think it's unreasonable to expect third party packagers to use a
bundled library if they're building on that old a system. They're
effectively shouldering the burden of providing security updates for
PHP regardless of what the distro does.

Adam

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

Re: [PHP-DEV] libpcre version requirements

[Adam Harvey]

On 11 August 2015 at 09:46, Christoph Becker cmbecke...@gmx.de wrote:
 What is the minimum libpcre version that is supported as external
 libpcre for ext/pcre?  According to config0.m4 it is PCRE 6.6
 (2006-02-06), but is this still valid and do we really have to support
 such old versions?

CentOS/RHEL 5 provides libpcre 6.6, which is probably where that
specific minimum version comes from. Someone out there is probably
still building packages that rely on this.

 I'm asking because of bug #70232 which can easily be fixed, but that
 requires PCRE 8.00 (2009-10-19).  If we have to support older PCRE
 versions, we'd probably need a fallback to the current behavior (which
 would obviously keep the bug).

I guess the question's really whether we should still support an
_external_ libpcre that old, since we bundle much newer versions. I
think the argument against changing it has always been that it works
and we didn't need anything newer, but if we have a reason now then
that doesn't really hold.

One problem is that I don't think we can really change the minimum
requirement on a stable branch, so for 5.5 and 5.6 we're going to have
to implement something that works with older versions regardless, but
I'd be for bumping the minimum version requirement for 7.0 if it makes
the code cleaner (on that branch, at least) moving forward.

Adam

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

Re: [PHP-DEV] PCRE JIT stack size limit

[Adam Harvey]

On 23 July 2015 at 11:47, Christoph Becker cmbecke...@gmx.de wrote:
snip great explanation, thanks
 Therefore I tend to prefer a new ini setting (say, pcre.jitstack_limit).
  That would mean, however, to add yet another ini setting, of which
 there are already so many.

I'm not a big fan of that, although it's at least in the spirit of
what configuration settings are meant to be used for.

What if we added the PCRE_ERROR_JIT_STACKLIMIT error constant to those
exposed to userland so that it's more easily noticed via
preg_last_error(), and adding a modifier that can be used to disable
the JIT on a per-pattern basis (by setting PCRE_NO_START_OPTIMIZE,
which admittedly disables other stuff too, but at least the regex will
run)? At least then users could check the error when the regex fails
and re-run the regex without the JIT if they chose to.

How likely is the average user to hit this, do you think?

Adam

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

Re: [PHP-DEV] Re: Announcing PHP 5.5 security-only

[Adam Harvey]

On 22 June 2015 at 16:05, Ángel González keis...@gmail.com wrote:
 @Adam, I was expecting the gory details to involve a of PHP commiters with
 black robes, faces hidden behind their hoods meeting overnight and an
 absurdly complex algorithm involving lunar cycles. instead you point to a
 manual override, but no descripcion on how it gets changed.

I left the robes out for time. The lunar cycle part is technically
correct (the best kind of correct).

That file's in the web/php repository, so anyone with web karma can
change it. I've added a 5.5 block to say that the last normal
release will be around the 10th of July. (I know it'll probably
actually be the 9th in much of the world, but let's cover Australia,
China, Japan, NZ, and friends.)

Stas, what are your plans for 5.4? Do you want me to adjust the EOL
date for that too?

Adam

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

Re: [PHP-DEV] Re: Announcing PHP 5.5 security-only

[Adam Harvey]

On 22 June 2015 at 14:10, Stanislav Malyshev smalys...@gmail.com wrote:
 Hi!

 ***
 The PHP 5.5 branch is going to enter in security only, and in the same
 time, PHP 5.4 will finally die
 ***

 I think http://php.net/supported-versions.php says we end 5.4 support on
 14 Sep 2015 so we have 2 more releases? Unless we have reason to change
 it or that page is wrong?

By default, the EOL dates are automatically calculated based on when
the first release on a branch occurred, but these can be overridden as
needed — see 
https://github.com/php/web-php/blob/master/include/branches.inc#L5-L21
for the gory details. I believe I set the 5.4 dates based on e-mails
last year, but don't have the references to hand.

If we have specific dates in mind for 5.4 and 5.5, I'm happy to update
the Web site to match (and do whatever Twitter publicity is required
via @official_php).

 In general, it would be nice to have a pre-announced final release
 instead of announcing it post-factum.

Agreed.

Adam

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

Re: [PHP-DEV] [RFC][VOTE] Improved Error Callback Mechanism

[Adam Harvey]

On 28 April 2015 at 15:10, Patrick ALLAERT patrickalla...@php.net wrote:
 Le mar. 28 avr. 2015 à 20:42, Kalle Sommer Nielsen ka...@php.net a écrit :

 I should probably have been faster at replying, but for PHP7 this is a
 no-go. I realize this is a pure internal change and have nothing to do
 with userland, but as currently is, we are in feature freeze and it
 creates a bad precedence between us as a team if we let this through
 now, sorry!


 No go? Isn't that a bit rough?

 That kind of change normally doesn't require an RFC at all. We did one for
 documentation purpose instead of just a PR and a mail saying ok for 7?.

I don't agree. This adds nine API functions and a few hundred lines of
code: if you _had_ just committed this, I have no doubt that you'd
have people asking you to revert it pending an RFC and a vote. This
isn't a bug fix.

Just because a feature is internal doesn't mean you can ignore the RFC
process. RFCs aren't just for language features: if they were,
Benjamin and I wouldn't have gone through the hassle of creating an
RFC for making gc_collect_cycles hookable a few months ago.

 Refusing this because we actually did an RFC to *document* it goes in the
 opposite direction of encouraging people to create them.

 Isn't this just a documented no brainer?

It's a good feature, the RFC is well written, and I have no doubt this
would be accepted for PHP 7.1. Indeed, it's something I could actually
make good use of in my day job.

None of that is the point.

We — as a development community — agreed to stop adding new features
to PHP 7.0 on a certain date so that we could work on stabilising what
we had and getting it out the door this year. That date was over a
month ago.

So, please, show respect for the people working hard on PHP 7.0 by not
trying to push something in against our agreed processes and making
more work for them.

Adam

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

Re: [PHP-DEV] Concern around growing complexity in engine - hash table specifically

[Adam Harvey]

On 8 April 2015 at 08:16, Anthony Ferrara ircmax...@gmail.com wrote:
 Sophistication is fine. What worries me though is magic. What worries
 me is the growing inability to debug with normal tools. Perhaps we
 need a GDB extension to provide tooling for common debugging tasks.
 Heck, even dumping a zend_string requires a cast (p (char*)str-val).

On that: we do already have a .gdbinit in php-src. I wonder if a
concrete thing that could be done right now to improve matters for
master would be to extend it on master to cover those sorts of common
operations that we're going to need to debug PHP 7.

Adam

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

Re: [PHP-DEV] Deprecate setlocale?

[Adam Harvey]

On 2 April 2015 at 12:24, Dan Ackroyd dan...@basereality.com wrote:
 On 2 April 2015 at 16:01, Keyur Govande keyurgova...@gmail.com wrote:


 To Rasmus's point, here's a PR for HHVM to provide a thread-safe setlocale
 implementation: https://github.com/facebook/hhvm/pull/4736/files

 It should be fairly easy to refactor the thread-safe-setlocale.(h/cpp) files
 for Zend.

 Ok, that' pretty awesome. So assumming that we incorporated that new
 thread safe version of locale, how would we expose it? Most people who
 are calling setlocale are unaware of it's side effects, and so should
 be using the new safe version by default.

 Some people who are calling setlocale will actually be using the
 cross-thread behaviour and so that still needs to work.

 setlocale is a variadic function, so it's not possible to hack in a
 flag parameter. As much as I dislike ini settings, it seems like
 adding one here would be sensible e.g. 'thread_safe_setlocale'

 * If it's enabled the setlocale function calls the new thread safe
 functionality.

 * If it's disabled the setlocale function calls the current non-TS C
 setlocale function.


 Does anyone have a better suggestion on exposing a thread safe version?

What about just adding another function: setlocale_global(), or
similar? I don't want a new INI setting any more than you do.

Adam

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

Re: [PHP-DEV] [RFC] Basic Scalar Types

[Adam Harvey]

On 11 March 2015 at 14:28, Bob Weinand bobw...@hotmail.com wrote:
 after all, some people are not happy with the current proposals about scalar 
 types. So, they both still possibly may fail.

 Thus, I'd like to come up with a fallback proposal in case both proposals 
 fail:

 https://wiki.php.net/rfc/basic_scalar_types

 It shouldn't prevent any future improvements and still give use all the 
 advantages of scalar types.

You have my axe, by which I mean +1.

Adam

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

Re: [PHP-DEV] Re: [VOTE] Remove deprecated functionality in PHP 7

[Adam Harvey]

On 5 March 2015 at 12:21, Pierre Joye pierre@gmail.com wrote:
 It would be good to do a pecl release for each of them, and mark the
 package as deprecated/overseeded by mysqli (I let you choose). Doing
 so will trigger a build there, cleaner.

I'm on the fence about making a release for ereg and mysql: it would
help in terms of code availability, but at the same time I feel like
it undermines our message of no, really, don't use these at all in
PHP 7, even though they'd be marked as unmaintained and deprecated.

I guess I'm open to persuasion either way here.

Adam

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

Re: [PHP-DEV] Re: [VOTE] Remove deprecated functionality in PHP 7

[Adam Harvey]

On 5 March 2015 at 05:39, Jan Ehrhardt php...@ehrhardt.nl wrote:
 I had already built a php_ereg.dll and a php_mysql.dll for PHP7, using
 the sources of two days ago. The config.w32 for ereg needs some changes,
 if you want to enable shared builds on Windows:

 http://git.php.net/?p=pecl/text/ereg.git;a=blob;f=config.w32

 -ARG_WITH(ereg, POSIX extended regular expressions, yes);
 +ARG_WITH(ereg, POSIX extended regular expressions, no);

 -   EXTENSION(ereg, ereg.c, PHP_EREG_SHARED, -Dregexec=php_regexec 
 -Dregerror=php_regerror -Dregfree=php_regfree -Dregcomp=php_regcomp 
 -Iext/ereg/regex /DZEND_ENABLE_STATIC_TSRMLS_CACHE=1);
 +   EXTENSION(ereg, ereg.c, PHP_EREG_SHARED, -Dregexec=php_regexec 
 -Dregerror=php_regerror -Dregfree=php_regfree -Dregcomp=php_regcomp 
 -Iext/ereg/regex);

Thanks; applied. I meant to ask someone to check the config.w32 files,
and was too braindead due to work and this by the time I sent the
e-mail to remember.

Adam

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

Re: [PHP-DEV] Re: [VOTE] Remove deprecated functionality in PHP 7

[Adam Harvey]

On 16 January 2015 at 09:16, Nikita Popov nikita@gmail.com wrote:
 I'll land the minor removals sometime soon; the unbundling of ext/ereg and
 ext/mysql should probably be done by someone else who's more into the PECL
 business.

They gone.

Many thanks to Tjerk, for doing all the hard work on the ereg front in
PR form, and Hannes for setting up the new Git repositories in the
PECL namespace for them to live in.

Adam, who feels sorry for MySQL users, who now have a mere two APIs to
choose from.

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

[PHP-DEV] Deadline for 7.0; was: [RFC][Discussion] In Operator

[Adam Harvey]

On 20 February 2015 at 04:54, Niklas Keller m...@kelunik.com wrote:
 Question: The timline says Line up any remaining RFCs that target PHP
 7.0., does that mean RFCs have to
 start voting on Mar 15 or should the vote end there?

My interpretation was that votes had to be concluded on or before
March 15 to be included in 7.0, but that is kind of ambiguous, now you
mention it.

Thoughts, fellow Internaleers?

Adam

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

Re: [PHP-DEV] [VOTE] Expectations

[Adam Harvey]

On 19 February 2015 at 01:09, Joe Watkins pthre...@pthreads.org wrote:
 The expectations RFC is now in voting phase:
 https://wiki.php.net/rfc/expectations#vote

Sorry, I had an e-mail backlog while this was in discussion, so I'm
only getting around to this now. Two thoughts:

1. This is awesome, particularly the BC aspects. Nice work. :)

2. For zend.assertions, is it worth defining constants with more
meaningful names that can be used in place of the magic values?
They're pretty arbitrary as it stands.

My vote's not conditional on that — I'm +1 even in its current form —
but I wonder if we can make this a little easier for users.

Thanks,

Adam

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

Re: [PHP-DEV] Deadline for 7.0; was: [RFC][Discussion] In Operator

[Adam Harvey]

(Please don't top post!)

On 20 February 2015 at 11:31, François Laupretre franc...@php.net wrote:
 My interpretation was that votes had to be concluded on or before
 March 15 to be included in 7.0, but that is kind of ambiguous, now you
 mention it.

 I would say that vote can *start*by March 15, as RFC is not supposed to 
 evolve after vote starts, hence 'feature freeze', but I have a personal 
 interest there because it would allow to vote on STH after people have enough 
 time to compare concurrent proposals, if there are. Otherwise, any work on 
 alternate proposal(s) can stop now, as it is too late to compete.

Just to be clear: if voting has to be finished by March 15, then
working backwards, the last date a new RFC can be submitted is this
Sunday:

- RFC discussion period starts: February 22
- RFC discussion period ends: March 8 (given the minimum of 2 weeks)
- RFC voting period starts: March 8
- RFC voting period ends: March 15 (given the minimum of 1 week)

Obviously those dates get shifted forward a week (so the last date for
a new RFC is March 1) if it's just that voting has to start by the
15th.

Would welcome other thoughts.

Adam

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

[PHP-DEV] [RFC] Comparable: the revenge

[Adam Harvey]

Hi all,

Those of you with long memories will remember that I proposed a
Comparable interface way back in the pre-5.4 days, but withdrew it
when it became obvious that there was no consensus for it as a feature
and that a vote was likely to fail.

RFC: https://wiki.php.net/rfc/comparable
PR: https://github.com/php/php-src/pull/1097

Why reanimate it now, I hear you ask? I think that comparisons have
only become more prominent in the language: we now have a spaceship
operator for explicit comparisons, yet the behaviour of object
comparisons can be obscure, to say the least, and the user has no
control over how their objects are compared.

At this stage, I intend to put this up for a vote on March 5 (vote
ending March 12), with the obvious endgame being that this would be
included in 7.0.

Thanks,

Adam

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

Re: [PHP-DEV] [RFC] Comparable: the revenge

[Adam Harvey]

I don't want to get into a lengthy debate (you have your opinion; I
have mine!), but to rebut a couple of specific points:

On 19 February 2015 at 14:19, Levi Morrison le...@php.net wrote:
 Another issue: it allows comparing an object to non-objects (even
 though the stated goal is only to compare two objects of the same
 type):

This is intentional. The wording in the introduction is probably a
little too specific to the object case — I'll fix that.

 class MyClass implements Comparable {
 private $val = 0;
 function compareTo($a) {
 return $this-val = $a;
 }
 }

 $int = 10;
 $myClass = new MyClass();
 $myClass = $int; // works
 $int = $myClass; // if this doesn't produce a warning it at least
 doesn't behave the same as the line above it

It does behave the same as the line above (with the result inverted,
obviously) — MyClass::compareTo() is still called in this case. The
only time ordering matters is if two objects are being compared, in
which case the leftmost one is the one that has its compareTo() method
called.

 But even here I would rather just take a function instead of requiring
 it to be the instance of some interface:

 function sort($input, callable $comparator($a, $b): int) {
 /* … */
 }

Fair, but the sorting case isn't the only one that matters,
particularly with = now as part of the language.

 I do want to thank you for taking the time to cite arguments, prior
 history and an alternative in the RFC. You have done a pretty good job
 on the RFC itself, in my opinion.

Thanks. :)

Adam

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

Re: [PHP-DEV] [RFC][VOTE][RESULT] Removal of dead or not yet PHP7 ported SAPIs and extensions

[Adam Harvey]

On 11 February 2015 at 06:59, Paul Dragoonis dragoo...@gmail.com wrote:
 On Mon, Feb 9, 2015 at 10:29 PM, Anatol Belski anatol@belski.net
 wrote:
 ext/mssql  17:13

 Did you accidentally miss out mssql? it resultes in significant resistance
 to leave core, such as mcrypt and ignoring mathematical numbers, from a
 practical basis I'd like to see mssql kept in core. Who's with me ?

Since it's apparently my week for this, I'll provide the case for the
defence (or why I voted for removal, anyway):

- The API is awful in the exact same ways the ext/mysql API was awful
— it makes it far harder to write secure code than it should be.

- Actually, it's worse than that, because there's no charset-aware
escaping function at all: the only option is addslashes(), which has
interesting security implications if you're using certain charsets.

- It's buggy. Some of the bugs are due to the underlying library
(which is mostly dead); some are in our code, but there are some
fundamental issues — basic data types (nvarchar(128), for example)
aren't supported, field names are truncated, stored procedure calls
are problematic, and probably many more things that I've forgotten.

- The bugs probably aren't going to be fixed. ext/mssql averages about
one to two non-whitespace, non-copyright-year-increment commits a
year. A cursory look at the bug tracker (or my ##php logs) will tell
you that it's not because it's stable and free of bugs.

- There are multiple better options: using ODBC is almost always more
stable, and while PDO_dblib has some of the same problems due to
FreeTDS, at least you're using PDO's better (by which I mostly mean
harder to misuse) API.

In my mind, this is analogous to removing ext/mysql: it's the right
thing to do for our users because it promotes better practices and
gets rid of an extension that has even more technical issues than that
one did.

Finally, Anatol's tally was wrong for this one: it was 17:3 for
removal. That's a pretty strong indicator by itself.

Adam

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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

[Adam Harvey]

On 6 February 2015 at 04:14, Andrea Faulds a...@ajf.me wrote:
 At long last, I’m going to put the RFC to a vote. It’s been long enough - I 
 don’t think there needs to be, or will be, much further discussion.

True, and I probably won't respond to any replies to this because we
don't need more noise, but I do want to explain my -1 vote. This is
long and rambling. I apologise. I've posted a formatted version of
this at https://gist.github.com/LawnGnome/354ca07f1799ff88fc35 in case
it's easier to read.

In no particular order, my issues with this RFC:

## The declare switch

Adding the cognitive overhead for each file for developers to have to
remember whether they have to cast a value before passing it to a
function or if PHP will automagically do that for them is a bad thing.
Of course, in a small, well compartmentalised file, or a single
developer code base, it wouldn't be a problem. Unfortunately, a lot of
PHP projects aren't that tidy. (Probably most of them, in fact.)

I also disagree with the comparisons that have been drawn on Internals
between `declare(strict_types=1)`, `use strict`, and `from __future__
import foo` statements. They're not the same thing at all:

* `use strict` is ultimately about code quality — am I doing something dumb?
* `from __future__ import foo` is ultimately about features — yes, I
want to opt-in for the new shiny.
* `declare(strict_types=1)` isn't either of those, although it might
superficially appear so — what it's really about is I reject your
philosophy and substitute my own in terms of typing.

There are structural decisions we can and should let our users make. I
believe this isn't one of them: allowing users to fundamentally change
the typing semantics of a language on a module-by-module level is, in
my opinion, insanity. Languages have to be opinionated about this sort
of issue: if they weren't, there'd only be one programming language
and it would have 800 switches to configure before you could write a
line of code. This sort of decision is the whole point of designing a
language: abdicating it by providing a switch is effectively us
shrugging and saying sure, whatever, we don't care, so now we'll make
you care.

## Strong typing

This ties into the previous point: for scalars, PHP has never been a
strongly typed language. I was once on the train of strict typing
being universally better — if you know that you always have an
integer, you never have to worry about a bad conversion, right? And,
if I was designing a language from scratch, I'd probably still feel
that way.

That language wouldn't be PHP, though. PHP is unapologetically weakly
typed from top to bottom. Designing a feature to break that would be
bad enough. Designing a feature to optionally break that is insidious.
If you care about whether the zval IS_STRING, you can check that
today. Encouraging our users to care goes against the entire
philosophy of the language.

To be clear: yes, we have problems in our type conversion matrix. The
fact that `21 Jump Street == 21` is an issue (particularly because
it's silent), and we should be talking about that. But strong typing
is not the solution.

## Caller versus callee

Making the caller responsible for choosing the type behaviour is a
clever hack. (No pun intended, Facebookers.) I find the idea
intriguing from an academic perspective. Unfortunately, as with the
above point, this isn't consistent with PHP as a language that's
existed for 20 years and had type hinting in its current form for over
10 years. If we accept this, then we only widen the gap between scalar
values and array/object ones: for one set of type declarations, the
behaviour is determined entirely by the callee, and for another, it's
determined by both the callee (via the type hint) and the caller
(whether it will be converted or not).

## So what do we do for 7.0?

From where I sit, we had a good solution: it was the 0.1 version of
this RFC. It behaved like PHP should behave, respected PHP's long
standing scalar type handling and conversion rules, but most
importantly, it solved the **actual** problem scalar type hints are
supposed to solve in the simplest possible way:

Can I guarantee that my function that expects an integer will
really get an integer?

I don't think that adding complexity on top of that helps anyone in
the long run. Yes, we get to tick some extra boxes — we support
strong typing, we support weak typing, we put the user in control
— but at the cost of having a language that not only supports, but
advertises multiple, inconsistent behaviours, requires users to be
aware of conversion minutiae that they shouldn't have to be mindful
of, and doesn't do anything to solve the actual problem above.

Adam

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

Re: [PHP-DEV] Re: [RFC][DISCUSSION] script() and script_once()

[Adam Harvey]

On 5 February 2015 at 13:06, Yasuo Ohgaki yohg...@ohgaki.net wrote:
 Since script()/script_once() is almost copy of require()/require_once(),
 it could be
 INI option.

 require_embed = On/Off

 Almost all users use 'require' only for script today, I guess.
 I should have included this option in RFC. I'll do that now.

I'd be very, very -1 on any new INI setting that changes language
behaviour. We should be getting rid of those, not adding them.

I'm not totally clear on what this RFC is proposing, honestly. Is the
new script statement meant to only include files that are entirely
wrapped in ?php and ? tags? Are files included that way assumed to
be PHP and don't require ?php and ? tags? Something else?

My initial reaction isn't positive, honestly — we already have four
statements that include files, and I'm not sure that another variation
is merited. There's only so much we can do to stop users shooting
their feet off: if don't use untrusted input for file names with
include/require isn't obvious, that's an education problem, not a
language one.

Adam

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

Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions

[Adam Harvey]

On 3 February 2015 at 03:11, Anatol Belski anatol@belski.net wrote:
 properly after the voting phase the
 https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts moves to the
 voting. Each item is voted separately. The voting ends on 2015-02-09 at
 21:00 CET.

To explain my -1s:

- ext/imap and ext/mcrypt: while I realise that the underlying
libraries are dead, these extensions are too widely used to straight
up remove them, I fear — we don't have obvious alternatives with
simple enough APIs that we can push users towards. I'd strongly
support and encourage a reimplementation of these extensions (in C or
PHP) around something supported if someone was able to step up and do
the work, otherwise yes, I'll pitch in to do the minimal work to port
these to 7.0 if required.

- ext/pdo_dblib: ODBC is almost always the better way of interfacing
with SQL Server, but I don't think keeping this one around is doing
anyone much harm (as opposed to ext/mssql, which we should kill with
fire for the same reasons as ext/mysql).

Abstentions:

- sapi/apache2filter: I wonder if someone would step up for that one
if we advertised more widely, given I believe that it is in actual
use. Unlike most of the other SAPIs, which are obviously dead, I'd
like to give this one a bit more time before the 7.0 feature freeze.

- sapi/milter: I'm at least passingly familiar with almost all of the
Web servers in the list, but I know nothing about the environments
this SAPI is used in. Can someone who is familiar with it describe the
pros and cons to dropping it?

- ext/sybase_ct: does PDO (via dblib and/or ODBC) cover this
functionality adequately? I feel that I know enough to vote on SQL
Server related topics, but haven't looked at actual Sybase for years.

Adam

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

Re: [PHP-DEV] Re: [RFC][VOTE] Turn gc_collect_cycles into function pointer

[Adam Harvey]

On 22 January 2015 at 00:56, Benjamin Eberlei kont...@beberlei.de wrote:
 On Wed, Jan 7, 2015 at 8:33 PM, Benjamin Eberlei kont...@beberlei.de
 wrote:

 Hello everyone,

 After discussion I am putting the RFC on turning gc_collect_cycles into a
 function pointer to vote:

 https://wiki.php.net/rfc/gc_fn_pointer

 Votes will end on 2015-01-21 19:31 (in 14 days).


 Sorry, I forgot to send a reminder, but given the results of 18-0 I think
 this is ok.

 The gc_fn_pointer RFC was accepted with 18-0! Thanks everyone :-)

Thanks Benjamin!

I've rebased my branch against master and created a PR:
https://github.com/php/php-src/pull/1023. If someone with Zend karma
would be so kind as to merge it, please, I'd appreciate it.

Alternatively, you may consider this my semi-annual reminder that I
don't have Zend karma and would like it. :)

Thanks,

Adam

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

Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors

[Adam Harvey]

On 20 January 2015 at 07:09, Kristopher kristopherwil...@gmail.com wrote:
 @everyone: Would an RFC be necessary to update the PHP manual to actually
 recommend the PHP 5 constructors and recommend against using the PHP 4
 style constructors, using very explicit language? If not, should this
 change be made, regardless of the outcome of the RFC to remove PHP 4
 constructors?

I'm happy to update the manual, but I think I'd want more of a
consensus (not necessarily a formal RFC, but at least a straw poll)
for soft deprecation (to reuse the term we used for mysql_* before
it started generating E_DEPRECATED messages but was deprecated in the
manual) before making the change.

Adam

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

Re: [PHP-DEV] Inconsistencies in callable, call_user_func and direct variable calls

[Adam Harvey]

On 20 January 2015 at 12:54, Marc Bennewitz dev@mabe.berlin wrote:
 valid for call_user_func[_array] and callable type-hint but invalid for for
 direct variable calls:
 - string MyClass::staticFunc
 - string self::staticFunc
 - string static::staticFunc
 - string parent::func
 - string parent::staticFunc

 see http://3v4l.org/1oSO3

 Thoughts ?

This is https://bugs.php.net/bug.php?id=68475 — Julien and I both have
PoC branches implementing this, and agree that it should be fixed in
PHP 7, although I think we differ on whether an RFC is required or
not.

Adam

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

Re: [PHP-DEV] [RFC] Skipping parameters take 2

[Adam Harvey]

On 17 January 2015 at 18:04, Andrea Faulds a...@ajf.me wrote:
 For consistency with list(), we could also just put nothing:


 foo($bar, , $baz);

 Which is like:

 list($bar, , $baz) = $arr;

 Thoughts?

That was Stas's original, original proposal way back when. I argued
then for having default as a placeholder, and still would today — in
the case where a function with, say, ten optional parameters[0] is
being called and eight of them should be the default, I think it's a
bit rough for somebody inheriting that code to have to count commas.
Having a token increases readability, IMO, and costs us nothing except
a few keystrokes, which isn't going to break the camel's back in a
language that requires function each time you declare a function.

Adam

[0] Yes, that's probably poor API design. You and I both know someone
will do it, though. :)

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

Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors

[Adam Harvey]

On 15 January 2015 at 17:35, Pierre Joye pierre@gmail.com wrote:

 On Nov 26, 2014 1:39 AM, Adam Harvey ahar...@php.net wrote:

 On 25 November 2014 at 10:36, Sara Golemon poll...@php.net wrote:
  On Tue, Nov 18, 2014 at 3:11 PM, Levi Morrison le...@php.net wrote:
  https://wiki.php.net/rfc/remove_php4_constructors
 
  Entirely +1 on removing them in PHP7.
 
  Did we decide on having a 5.7 release? (I was on vacation and may have
  missed this) If so, then the timeline is perfect, one full release to
  deprecate, and a major-version bump to remove on.

 Not as yet, but it seems inevitable. If Zeev's PHP 7 timeline RFC
 pases, I was going to write up the let's do a 5.7 RFC if nobody else
 did.

 Yes, we did. And we decided not to have it because it will impact php7
 timeline.

That e-mail was almost two months ago. :)

Adam

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

Re: [PHP-DEV] [RFC] Skipping parameters take 2

[Adam Harvey]

On 14 January 2015 at 11:15, Marc Bennewitz dev@mabe.berlin wrote:
 But I think adding default as new keyword is a big BC break!

Default already is a keyword: http://php.net/switch. There's no BC break.

 I personally also don't like it and asked myself why can't the parameter
 simply skipped?

That was in the original proposal, but counting commas is pretty lousy
if you're skipping more than one or two parameters. Having a keyword
makes it more readable.

Adam

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

Re: [PHP-DEV] journald support for Linux systems that use systemd

[Adam Harvey]

On 8 January 2015 at 01:39, Markus Fischer mar...@fischer.name wrote:
 On 08.01.15 02:14, Johannes Schlüter wrote:
 On Wed, 2015-01-07 at 17:01 -0500, Mark Montague wrote:
 I'd like to start an RFC (see the draft proposal at the end of this
 message) for adding
 journald support to PHP on Linux systems that use systemd.  This message
 is to
 measure reaction to the intended proposal prior to requesting RFC karma.

 I believe the sd_journal_* functions could go in a PECL version, for the
 logging I'd love if logging could be cleanup in a way that we have a
 good internal API for internal use as well as integrates with userlevel
 expectations (- PSR 3 Log)

 That would have been my reaction too, but looking at the diff it plays
 on the same level as the syslog logging, i.e. it's integral in the
 system in parts where a PECL extensions couldn't reach ...

I think that's Johannes's point, though: if we can extend our internal
logging API to support these special case log file names in a central
place and allow extensions to register new ones, then journald support
could be implemented as an extension and we wouldn't have to touch
those bits of code.

I'd probably be -1 on the patch as it stands (this doesn't need to be
in php-src right now; syslog has the advantage of being a standard
cross-platform interface, which this isn't), but +1 on doing the work
to support that.

Adam

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

Re: [PHP-DEV] [RFC] Extension Prepend Files

[Adam Harvey]

I'm going to be a bit hazier than normal in this e-mail, for which I
apologise. People who know who I work for, you can probably guess the
parameters of the NDA I'm trying not to break here.

On 8 January 2015 at 04:38, Benjamin Eberlei kont...@beberlei.de wrote:
+1 on everything I snipped
 Examples of good use-cases for this feature:

 1. Low-Level MongoDB connection code in C, userland OOP API in PHP.
 2. Low-Level Crypto code, simplified PHP functions (think ext/hash +
 ext/password)
 3. Database Vendor Extensions in C + common DB abstraction in PHP (PDO2).
 4. Low-Level Date handling, high level PHP code

Let me toss another use case onto the fire.

Imagine you have an extension that replaces the zend_execute_ex
pointer so it can fire hooks before and after a particular function is
called. You can write those hooks in C, but there's no actual reason
they need to be — they're not performance-critical, and don't require
access to any internal APIs.

At that point, it would be nice to have a mechanism for shipping PHP
code with your C extension that doesn't require any external
dependencies. As Derick says, pecl install foo, not pecl install
foo  composer require foo/bar  some sort of startup code in
userland.

This code isn't optional: it's required for your extension to behave
properly. It's intimately tied to the exact extension you're shipping
— you don't want to expose a stable API to userland for this, because
there's no need, and it's irrelevant for users anyway. Why not allow a
way for extension authors to ship this code as (hopefully) safe,
managed PHP instead of C, in a way that isn't reliant on tooling and
could allow version drift between the C and PHP code bases?

This isn't a new idea. We've talked on IRC about shipping bits of the
standard library as PHP code instead of C for years. Having this
mechanism — whatever form it ends up taking — would help there.

 I should rewrite the RFC and remove the implementation details, because
 essentially the solution could also be tooling based (vs code based).

It could, but I think there's a benefit in having a non-tooling based
way to do it. Much as I (genuinely) wish everything was open source
and could be installed through PECL, there are plenty of closed source
extensions for PHP.

Adam

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

Re: [PHP-DEV] PHP 5.5.21RC1 is ready for testing

[Adam Harvey]

On 8 January 2015 at 10:24, Remi Collet r...@fedoraproject.org wrote:
 Is this expected ?

 Notice the diff between (see attachement) :
 - - 5.4.35 and 5.4.36   show 5 changes,
 - - 5.5.20 and 5.521RC1 show only 2
 - - 5.6.4  and 5.6.5RC1 show only 2

Since you mentioned on IRC that this seemed inconsistent, I added an
explicit test for this: it works the same on 5.5, 5.6 and master. I
think the key is that this is new since the last round of stable
releases.

I'll update the documentation to mention this.

Adam

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

Re: [PHP-DEV] Faster zend sorting implementation

[Adam Harvey]

On 5 January 2015 at 18:39, Xinchen Hui larue...@php.net wrote:
 On Tue, Jan 6, 2015 at 2:04 AM, Tim Düsterhus t...@bastelstu.be wrote:
 On 05.01.2015 18:08, Xinchen Hui wrote:
 do you think such BC break is acceptable? or I still need a RFC? :


 Chiming in as a pure userland developer. The documentation already states:

 Note: Like most PHP sorting functions, sort() uses an implementation
 of » Quicksort. The pivot is chosen in the middle of the partition
 resulting in an optimal time for already sorted arrays. This is however
 an implementation detail you shouldn't rely on.
 thanks, then I think no problem.

 the reason why I asked is I found lots of test scripts starts to fail,
 they all rely on the current non-stable sorting algo :

We make no promises about the implementation on any of the relevant
documentation pages, besides that it's a quick sort, and we explicitly
say that you can't rely on that. I think we can change this without a
real BC concern (although it would still be worth noting in UPGRADING
and, by extension, the migration guide).

Adam

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

Re: [PHP-DEV] [RFC] Scalar Type Hints

[Adam Harvey]

On 31 December 2014 at 12:27, Andrea Faulds a...@ajf.me wrote:
 Parameter type hints for PHP’s scalar types are a long-requested feature for 
 PHP. Today I am proposing an RFC which is a new attempt to add them to the 
 language. It is my hope that we can finally get this done for PHP 7.

 I’d like to thank Dmitry, who emailed me and gave me some feedback on the 
 draft RFC and some improvements to the patch. He encouraged me to put this to 
 internals sooner rather than later, as it’s a feature many people are hoping 
 will be in PHP 7.

 The new RFC can be found here: https://wiki.php.net/rfc/scalar_type_hints

At a first read through, this looks great, and much more in line with
what I'd like scalar type hints to look like. Nice job!

In terms of the open issues, here's what I think:

1. Aliases: I think we should support the same set of names as we
currently support for type casts[0] (excluding non-scalar types,
obviously) — this actually expands the list a little more, since there
are three (!) variants for floating point values, but I think it's
important to be consistent in all the places in the language where we
use type names.

2. Prohibiting use in class names: I think this makes sense, otherwise
we'll be violating the principle of least surprise when somebody does
call a class Int. (Yes, namespacing might help here, but I think I'd
rather restrict it altogether rather than trying to come up with rules
around when you can call a class int and how you'd refer to it.)

To bang another drum (and this shouldn't be responded to in this
thread, since we have another one going for this RFC): this sort of
change is why 5.7 is vital for migration — emitting deprecation
warnings for users calling classes by names that we'll be prohibiting
in PHP 7 is important, and will help our users migrate their code
bases.

I haven't looked at the patches yet, but assuming they're good, my
initial feeling is +1. Good work on taming the beast. :)

Adam

[0] 
http://php.net/manual/en/language.types.type-juggling.php#language.types.typecasting

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

Re: [PHP-DEV] [RFC] PHP 5.7

[Adam Harvey]

On 16 December 2014 at 10:38, Stanislav Malyshev smalys...@gmail.com wrote:
 I've tried to search the ML for such list of RFCs:

 https://wiki.php.net/rfc/gc_fn_pointer
 https://wiki.php.net/rfc/secure_unserialize (also 5.6 if RMs agree)
 https://wiki.php.net/rfc/closure_apply
 https://wiki.php.net/rfc/pack_unpack_64bit_formats (targeting 5.6)
 https://wiki.php.net/rfc/intdiv
 https://wiki.php.net/rfc/session.user.return-value

 maybe others too, but I got bored ;)

 Didn't I hear no features? Most of these are features.

True, but none of them have been accepted for _this_ 5.7. As Andrea
said, her 5.7 RFCs simply used that as a placeholder for what is now
7.0, since that was the master version number at the time. The same is
true of Sara's session return value RFC. The new pack and unpack
formats are in 5.6 already, I believe, so wouldn't be new to 5.7.
Secure unserialise was your RFC, so you tell us. :)

The only one that's pending and actually applies here is the GC
function pointer RFC. As co-proposer, I'd obviously like to see it in
5.7 as well (there's no user impact, it's so trivial it probably
doesn't even qualify for copyright protection, and it's useful for
profilers), but I'm happy to accept that it might be a casualty of the
no features rule.

In summary: our current state would allow us to have a no features
rule and for it to make sense with what's already been accepted.

Adam

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

Re: [PHP-DEV] [RFC] PHP 5.7

[Adam Harvey]

On 16 December 2014 at 13:18, Andrea Faulds a...@ajf.me wrote:
 Hmm, actually, a 2to3-esque tool and a formal extension of 5.6's support by a 
 year sounds like a better solution. If others agree, I might withdraw this 
 RFC.

I disagree. 2to3 wasn't a success in the Python world — in the end,
the only migration solution that worked there was code bases that
could run on both Python 2 and 3 (with the help of userland
compatibility libraries like six and python-future), and I believe the
same will be true for PHP 5 and 7.

More generally, I don't believe a standalone CLI tool can be the whole
answer even if that wasn't a problem: too many of our users only ever
run their code in shared Web server environments and aren't proficient
enough at the command line (on whatever OS they choose) for that kind
of tooling.

I'm sure someone will write a 2to3 type tool, and that some people
will find it useful, but I don't think it's the right answer in terms
of advertising a migration path.

Adam

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

Re: [PHP-DEV] [RFC] PHP 5.7

[Adam Harvey]

On 16 December 2014 at 14:00, Zeev Suraski z...@zend.com wrote:
 - We cannot patch 5.6 to add any Warnings-of-any-kind (stable release,
 under release process that forbids that)

 What part of the release process forbids that?

None, but I'd still advocate releasing a new minor because there's
plenty of anecdata suggesting that our userbase tend to consider 5.x.y
and 5.x.y+z to be the same in terms of features. We used to see this
confusion in ##php a lot over things like crypt() algorithm support
changing over the course of 5.3: trying to explain that you don't want
to use anything before 5.3.7 is actually surprisingly difficult,
whereas saying 5.4 fixes this is easy.

Adam

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

Re: [PHP-DEV] [RFC] PHP 5.7

[Adam Harvey]

On 16 December 2014 at 14:19, Zeev Suraski z...@zend.com wrote:
 -Original Message-
 From: a...@adamharvey.name [mailto:a...@adamharvey.name] On
 Behalf Of Adam Harvey
 Sent: Wednesday, December 17, 2014 12:10 AM
 To: Zeev Suraski
 Cc: PHP Internals
 Subject: Re: [PHP-DEV] [RFC] PHP 5.7

 On 16 December 2014 at 14:00, Zeev Suraski z...@zend.com wrote:
  - We cannot patch 5.6 to add any Warnings-of-any-kind (stable
  release, under release process that forbids that)
 
  What part of the release process forbids that?

 None, but I'd still advocate releasing a new minor because there's plenty
 of
 anecdata suggesting that our userbase tend to consider 5.x.y and 5.x.y+z
 to
 be the same in terms of features. We used to see this confusion in ##php a
 lot over things like crypt() algorithm support changing over the course of
 5.3:
 trying to explain that you don't want to use anything before 5.3.7 is
 actually
 surprisingly difficult, whereas saying 5.4 fixes this is easy.

 My view, though, that if we think that delivering those deprecation messages
 is critical, we're facing a choice between two less-than-ideal options.  The
 5.7 option defeats the purpose for which it's built - getting a substantial
 number of people to upgrade and see those messages in the first place.

I think it's actually more likely that people will upgrade to a new
minor than a later revision that includes deprecation warnings in the
long run. There's a decent amount of evidence that suggests that users
tend to stick to their distro packages for minors, and those tend to
be early in the minor cycle (the various version links at
http://w3techs.com/technologies/details/pl-php/5/all are interesting,
and I've seen non-public data that indicates the same thing).

 It'll also create an awkward and maybe even silly situation where we'd have
 two active versions - both with its own monthly releases, but effectively
 virtually identical to each other in every regard except for these messages.

For twelve months, until 5.6 enters extended support. I think that's
manageable, and although it might seem silly internally, I think it's
also a better result for our users in terms of managing their
migration paths.

Adam, who's pretty much going to bow out of the conversation for now,
since he's said everything he wanted to.

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

Re: [PHP-DEV] On the road to PHP 5.7 , or not ?

[Adam Harvey]

On 12 December 2014 at 23:19, Zeev Suraski z...@zend.com wrote:
 3.  Last (and probably least) - a 5.7 that breaks compatibility is
 inconsistent with our version strategy, that suggests 5.7 should be fully
 compatible with 5.6.

Whoa — I'm not talking about breaking compatibility. I'm talking about
generating deprecation warnings on things we know are going to break
in PHP 7.

Travelling backwards a point:

 2.  My position about 5.7 that's minimally different from 5.6 and just
 'helps migration', is that it's practically useless.  Users won't go through
 the headache of hopping through two versions, for some supposed unknown
 benefits.  PHP 7 breakage is going to be fairly localized to specific
 areas - not so much the engine changes which barely breaks anything.  So if
 5.7 'breaks' the same areas that 7.0 does (keywords, warnings in the right
 places, etc.) - migrating to it would essentially be as painful (or
 painless) as migrating to 7.0.  In other words, no benefits to doing this
 extra step from the point of view of most users.

As I said, 5.7 wouldn't break anything, to my mind. The point is to
provide a way for users to get a heads up on what things they need to
be looking into to either migrate to PHP 7, or have a single code base
that runs on both PHP 5 and 7, depending on their needs.

The Python experience suggests that both of these cases _need_ to be
supported, and well. Why wouldn't we — the people best placed to do so
— provide the tooling to do that as part of the runtime?

The strawman version of your position seems to be that users are going
to just migrate to PHP 7 en masse, and that they'll be happy with
their code breaking to tell them what to fix. I'm not sure there's any
history in PHP or other languages that suggests that's really what
will happen, and I think we're doing our users a disservice if we
don't make the path to having a mixed 5/7 code base as easy as
possible.

Adam

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

Re: [PHP-DEV] On the road to PHP 5.7 , or not ?

[Adam Harvey]

On 15 December 2014 at 08:51, Derick Rethans der...@php.net wrote:
 Yes, I disagree. It's a time thing. Let's all work on one thing instead
 of *two*. Clearly you must see that there is not enough bandwidth? It
 will also prevent people from oh we can get this into 5.7 nonsense.
 It's not helpful, and it *is* fragmenting development.

I'm just as cognisant of our time constraints as you are, but I still
think this can work if there's a clear, written expectation (say via
RFC) that 5.7 is for migration related changes only, and should not
include new feature work. If we can keep this as 5.6 + some
deprecation warnings, I believe that can reduce the QA/development
load enough to make delivering it and 7.0 possible next year.

Adam, who apparently put his optimistic pants on this morning.

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

Re: [PHP-DEV] On the road to PHP 5.7 , or not ?

[Adam Harvey]

On 12 December 2014 at 10:07, Levi Morrison le...@php.net wrote:
 Just because we are releasing PHP 7.0 next year (well, according to
 our timeline anyway) that doesn't mean we can't release a 5.7.

Agreed.

I have to apologise here — I've had a draft RFC half-written for over
a week at this point that would lay out a timeline and scope for PHP
5.7 (and think I mentioned it on IRC, so I'm sorry if I forestalled
someone else doing the same), and haven't had time to finish it and
send it due to travelling.

 The advantage of PHP 5.7 is clear to me at least: it would extend
 support for the 5.X series by another year, get bug fixes, and contain
 E_DEPRECATED warnings and other things that should make migrating to
 PHP 7.0 easier. I personally do not suggest adding any features in PHP
 5.7.

I completely agree: 5.7 should happen, and should include deprecation
warnings where appropriate, reserve any keywords that will be reserved
in PHP 7, and generally make it easier to maintain code that works on
both versions.

In terms of timeline: I think we could (and should) release this in
August, assuming we stick to the limited scope above. We could really
branch any time from PHP-5.6. We'll know what new warnings need to be
in 5.7 by mid-March, per the PHP 7 timeline, and could then start the
alpha/beta cycle there: in general, less testing should be required
than normal compared to the last few versions due to the scope, and
4-5 months would be plenty to get through testing, even given that
most people would be (understandably) focused on PHP 7.

Adam

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

Re: [PHP-DEV] Fwd: [php-src] Constant-Time bin2hex() implementation (#909)

[Adam Harvey]

On 26 November 2014 at 08:49, Ferenc Kovacs tyr...@gmail.com wrote:
 That's a rather extreme reaction to trying to patch string operations that
 real-world frameworks use to handle crypto secrets, don't you think?

 and there are at least that much, but probably lot more usages in the
 wild(see https://github.com/search?l=phpq=bin2hextype=Codeutf8=%E2%9C%93
 for example) where there is nothing to do with security so there is no gain
 for being constant time, but those users would get the performance
 degradation.

Agreed. I've never really thought of those functions as being
cryptographically significant.

 I think it would be better to introduce constant time alternatives for
 functions like this instead of trying to replace them and require everybody
 to pay the performance price.

+1 on this too: if we added a new function for constant time string
comparison (which is, IMO, the far more common crypto case requiring
this sort of work) rather than modifying strcmp(), I don't see why any
of these should be different.

I do wonder if these need to be in core, or if a PECL extension would
be more appropriate.

Adam

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

Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors

[Adam Harvey]

On 25 November 2014 at 10:36, Sara Golemon poll...@php.net wrote:
 On Tue, Nov 18, 2014 at 3:11 PM, Levi Morrison le...@php.net wrote:
 https://wiki.php.net/rfc/remove_php4_constructors

 Entirely +1 on removing them in PHP7.

 Did we decide on having a 5.7 release? (I was on vacation and may have
 missed this) If so, then the timeline is perfect, one full release to
 deprecate, and a major-version bump to remove on.

Not as yet, but it seems inevitable. If Zeev's PHP 7 timeline RFC
pases, I was going to write up the let's do a 5.7 RFC if nobody else
did.

Adam

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

Re: [PHP-DEV] [RFC] Unicode Escape Syntax

[Adam Harvey]

On 24 November 2014 at 14:21, Sara Golemon poll...@php.net wrote:
 On Mon, Nov 24, 2014 at 2:09 PM, Andrea Faulds a...@ajf.me wrote:
 Here’s a new RFC: https://wiki.php.net/rfc/unicode_escape

 I'm okay with producing UTF-8 even though our strings are technically
 binary.  As you state, UTF-8 is the de-facto encoding, and recognizing
 this is pretty reasonable.

I'm also OK with this, although I do wonder if we should be respecting
the user's default_charset setting instead. (Since default_charset
defaults to UTF-8, in practice this isn't a significant difference
for the average user.)

 You may want to make it a requirement that strings containing \u
 escapes are denoted as:   ublah blahWe set aside this format
 back in the PHP6 days (note that bblah is equivalent to blah for
 binary strings).

It seems to me that the point of \u and \U escapes is to embed Unicode
in potentially non-Unicode strings, so using u doesn't feel right.

 On the BMP versus SMP issue of \u styles, we addressed this in
 PHP6 by making \u denote 4 hexit BMP codepoints, while \U denoted six
 hexit codepoints.   e.g.\u1234 === \U001234   I'd rather
 follow this style than making \u special and different from hex and
 octal notations by using braces.

I think I prefer the brace style, personally. Non-BMP codepoints have
become more important since PHP 6 (thanks, emoji), and having \u and
\U be case sensitive when \x isn't seems confusing.

Adam

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

Re: [PHP-DEV] [RFC] Unicode Escape Syntax

[Adam Harvey]

On 24 November 2014 at 14:35, Andrea Faulds a...@ajf.me wrote:

 On 24 Nov 2014, at 22:30, Adam Harvey ahar...@php.net wrote:
 I'm also OK with this, although I do wonder if we should be respecting
 the user's default_charset setting instead. (Since default_charset
 defaults to UTF-8, in practice this isn't a significant difference
 for the average user.)

 Ooh, that would be a possibility. That or using whatever encoding the source 
 file is specified to be with declare(), so it matches the encoding of other 
 characters in the string.

 This’d add significant complexity to it, though (would we have to require ICU 
 or something? D:), plus the vast majority of Unicode characters will only be 
 supported by Unicode encodings… and of those, only UTF-8 is really in much 
 use here anyway.

We would have to require ICU, but that might be worthwhile for PHP 7
anyway. Having at least one i18n API that's guaranteed to be available
would be nice.

 You may want to make it a requirement that strings containing \u
 escapes are denoted as:   ublah blahWe set aside this format
 back in the PHP6 days (note that bblah is equivalent to blah for
 binary strings).

 It seems to me that the point of \u and \U escapes is to embed Unicode
 in potentially non-Unicode strings, so using u doesn't feel right.

 I don’t really see where you’re coming from, it also makes just as much sense 
 within Unicode strings. There are plenty of cases (like the U+202E or mañana 
 examples in the RFC) where you’d want a Unicode escape in a Unicode string.

I probably worded that badly — I just mean that I don't think \u and
\U should be limited to only u strings, but should work in normal
strings as well. (In other words, I'm agreeing with what's in your
RFC, not with Sara.)

Adam

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

Re: [PHP-DEV] [VOTE] [RFC] PHP 7.0 timeline

[Adam Harvey]

On 21 November 2014 07:36, Ferenc Kovacs tyr...@gmail.com wrote:
 In this case the 3 month period will be too short imo.
 We release RCs/betas every two weeks, so 3 months would be about 6 release.
 5.6.0 had 3 alpha, 4 beta and 4 rc before release.
 5.5.0 had 6 alpha, 4 beta and 3 rc before release.
 5.4.0 had 3 alpha, 2 beta and 8 rc before release.
 5.3.0 had 3 alpha, 1 beta and 4 rc before release
 5.2.0 had 6 rc before release.
 5.1.0 had 6 rc before release.

 based on that I would say that our average beta+rc release number is around
 7, and sometimes the release for a beta/RC can be delayed, so I think that
 having only 3 months for the beta+RC period is too optimistic, we should
 make that into 4 months at least, we could either push out the ETA for GA
 or move back the alpha period by a month.

Agreed. This is the key reason why our annual release cycle has been
15 monthly in practice — we've consistently underestimated the
number of beta and RC releases required for a .0 stable.

Adam

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

Re: [PHP-DEV] [VOTE][RFC] Safe Casting Functions

[Adam Harvey]

My -1 is pretty much the same as Levi's:

On 19 November 2014 13:57, Levi Morrison le...@php.net wrote:
   - The RFC does not address how this is different from
 FILTER_VALIDATE_* from ext/filter. I know there was a mention of this
 on the mailing list, but the RFC should say why a tool that already
 exists to solve this kind of problem is insufficient, especially when
 it is enabled by default.

I'm also somewhat concerned that these functions are conflating two
concerns (validation and conversion).

   - PHP suffers a lot from function bloat and this RFC provides
 multiple functions that do the same thing but differ only in how they
 handle errors. A simple validation of can this be safely cast to an
 integer without dataloss? avoid the issue entirely and would be fewer
 functions.

+1: the idea of adding two sets of identical functions except for how
they signal errors isn't one I like.

Derick raised a good point elsethread: this is really tied into how we
want to signal errors in PHP 7. If we switch to exceptions, then let's
figure out a plan of attack and switch to exceptions everywhere, not
just in the odd function here and there. If we don't, then the to_*
functions shouldn't be added.

 To summarize: I like the idea of having tools that helps us convert
 between types in a lossless way, but I don't think this proposal is
 what is best for PHP. -1 for me but I hope to see this revisited.

I don't know that I'd ever be a strong +1 on this (adding more type
conversion matrices to PHP doesn't seem like a good idea to me,
whether it's in the language itself or in the standard library, and I
feel like we have the validation part of this already in filter and
ctype), but if we figured out the error handling situation and had
only one set of functions, I could probably grit my teeth and abstain,
at least.

Adam

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

Re: [PHP-DEV] [VOTE][RFC] Safe Casting Functions

[Adam Harvey]

On 20 November 2014 18:06, Andrea Faulds a...@ajf.me wrote:

 On 21 Nov 2014, at 00:45, Adam Harvey ahar...@php.net wrote:

 On 19 November 2014 13:57, Levi Morrison le...@php.net wrote:
  - The RFC does not address how this is different from
 FILTER_VALIDATE_* from ext/filter. I know there was a mention of this
 on the mailing list, but the RFC should say why a tool that already
 exists to solve this kind of problem is insufficient, especially when
 it is enabled by default.

 While that was true when Levi said it, the RFC *does* address this now.

That's fair — I read the RFC again when it first came up for vote, in
my defence, but wanted some time to think about it. I should have
re-read it before actually voting. Sorry about that.

The clunkiness of the filter API is a valid point, although I don't
think unconditionally adding a bunch of unnamespaced functions — which
can be implemented in userspace just fine — is the right way of
dealing with it.

(I've snipped your rationale and example. Thanks for writing it — I
don't necessarily agree with it, but it's a good explanation of your
thinking, and probably something that would have helped the RFC.)

  - PHP suffers a lot from function bloat and this RFC provides
 multiple functions that do the same thing but differ only in how they
 handle errors. A simple validation of can this be safely cast to an
 integer without dataloss? avoid the issue entirely and would be fewer
 functions.

 +1: the idea of adding two sets of identical functions except for how
 they signal errors isn't one I like.

 The problem is that it’s the least bad of the available options.

I disagree. To my mind, the best option right now (barring the status
quo, which realistically I'd prefer) would be the try_* functions
only. They line up with how ext/standard (and pretty much all of PHP
other than a smattering of OO functions and SPL) signal errors, and
avoid duplication. I don't really fancy explaining the difference
between to_* and try_* in ##php to a new developer.

PHP may be a mishmash of undesigned APIs in places, but that doesn't
mean we should dump fuel on the fire by adding two parallel APIs that
are named obscurely and differ only in how they signal errors.

 Derick raised a good point elsethread: this is really tied into how we
 want to signal errors in PHP 7. If we switch to exceptions, then let's
 figure out a plan of attack and switch to exceptions everywhere, not
 just in the odd function here and there. If we don't, then the to_*
 functions shouldn't be added.

 This isn’t a switch, though, these are new additions. We already have 
 exceptions in a few places in core, and there’s nothing wrong with new 
 additions using exceptions if and when appropriate. The question is over how 
 to deal with legacy code.

There's no function in php-src today that throws an exception outside
of an OO context. (Indeed, if you go through the various classes and
methods in php-src, I suspect even _in_ an OO context the majority of
errors are signalled via return values or PHP errors.)

Right now, the standard for appropriateness when adding an exception
is pretty much is this an error generated in an OO context? This
clearly isn't.

To be clear: if a way could be designed to do it without shredding BC,
I'd be ecstatic if we deprecated our current error handling system
entirely in favour of exceptions in PHP 7. But that's not the standard
right now, and an unrelated RFC like this isn't the place to make that
decision.

 In this specific case, I suppose the other option would have been to throw an 
 E_RECOVERABLE_ERROR. But exceptions can be handled easier, and so I don’t see 
 a particular reason why it shouldn’t throw an exception.

Why would you throw an E_RECOVERABLE_ERROR? The error's been
signalled: the function returned NULL, rather than an
int/float/string.

Adam

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

Re: [PHP-DEV] forbid use declaration outside of a namespace in PHP 7

[Adam Harvey]

On 11 November 2014 04:11, Robert Stoll p...@tutteli.ch wrote:
 I always found it very ugly that it is possible to define a use outside of a 
 namespace. Consider the following:

 namespace{ //default namespace
 }

 use foo\Bar;

 namespace test{
   new Bar(); //error, test\Bar not found }

 After some thoughts it is quite clear that Bar is test\Bar and not foo\Bar 
 inside of the namespace test. But consider
 the
 following example which is not so obvious:

 use foo\Bar;
 namespace test;
 new Bar(); //error, test\Bar not found

 The use declaration looks like a normal use declaration at first glance.
 I do not see why we should actually support this feature any longer and 
 thus suggest to remove it in PHP 7.
 Although, it is
 not a bug (the use declaration is simply ignored as far as I can tell) I 
 suppose it confuses the user.
 Nevertheless, even if we declare it as a feature I think it should at 
 least not be a feature of the specification
 of PHP 7.

Sorry, I apparently missed this the first time. Would this mean that
this sort of script (where we're using use statements without a
namespace) would no longer work?

?php
use GuzzleHttp\Client;

include __DIR__.'/vendor/autoload.php';

$client = new Client;
// $client is a GuzzleHttp\Client object
?

Because that strikes me as an irritating and unnecessary BC break for
people who are writing throwaway scripts (with no need to live in
namespaces) that pull in namespaced libraries to me.

Adam

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

Re: [PHP-DEV] Currently supported versions of PHP

[Adam Harvey]

On 27 October 2014 18:29, Sebastian Bergmann sebast...@php.net wrote:
 On 10/27/2014 10:45 AM, Peter Cowburn wrote:
 The closest we have, at the moment, is probably http://php.net/eol.php
 which details the versions which are no longer supported.

  We need the inverse of that :)

 Good question.

  Should we start http://php.net/supported-versions.php then?

I did most of the work to support this a few weeks back, as the bug
tracker needed to be able to pull the currently supported versions
from somewhere when qa.php.net is down, so this is mostly just a case
of wiring up the data into something readable.

It hasn't propagated to all the mirrors yet, but we now have
http://us2.php.net/supported-versions.php, as suggested. I used the
Wikipedia table for inspiration (that is, I blatantly stole the
formatting), and also added a basic SVG calendar which people seem to
like when I show it in conference talks.

Thoughts? (I haven't linked it from anywhere yet, so it's not really
live as such.)

Adam

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

Re: [PHP-DEV] Currently supported versions of PHP

[Adam Harvey]

On 28 October 2014 05:32, Stas Malyshev smalys...@sugarcrm.com wrote:
 The page looks good, but we've moved 5.4 to security-only on 18 Sep 2014
 (5.4.33), and it'll be supported for 1 year starting that date.

Good catch — I meant to put in a more generic ability to override the
support dates in include/branches.inc, but forgot before I pushed.
I've just pushed an update that does that (and sets the dates for
5.4); you should see it on mirrors in the next hour.

Thanks,

Adam

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

Re: [PHP-DEV] Thoughts on the PHP.net website

[Adam Harvey]

On 25 October 2014 03:15, Rowan Collins rowan.coll...@gmail.com wrote:
 Daniel Ribeiro wrote on 24/10/2014 19:52:

 *Disclaimer: *I wanted to bring this discussion inside the internals
 mailing list not only because of the fact that the PHP.net website's
 source
 code on GitHub doesn't have issues enabled, but especially because I think
 it's part of the PHP environment, just like the spec or the actual C code
 itself.

 In this case, I would have thought either php.webmaster or php.doc would be
 more appropriate than php.internals, which really does tend to focus on the
 internal implementation of the language, rather than how it used or
 documented.

Yep, this is php.webmaster material (I've cc:d that list, and would
suggest that follow ups should probably go there and exclude
Internals). #php.doc on efnet is also a good place to float things
more informally, particularly if you hit it at the right time of day
(morning/early afternoon PST tends to be good, given a lot of the
regular Web site committers are in North America).

 Meanwhile, I agree with both Kris and Andrea's responses: you need to be
 specific about what problems you propose to fix, and you need to be
 extremely wary of breaking existing functionality just because it's
 interesting or modern.

+1.

There are also a lot of technological constraints that aren't obvious
at a glance: not controlling our (entirely volunteer) mirrors means
that the baseline PHP functionality we can rely on is much, much lower
than you may expect. (Don't even ask about databases.) Remember, we
have literally no budget, and rely entirely on the generosity of our
hosting sponsors.

I'm certainly not claiming that what we have in web-php today is good,
but it has the advantage of having been proven over a very long period
of time, being easily and widely distributed, and coping with the
loads that it has to. A rewrite would have to have compelling
advantages over that, and be done for better reasons than just the
existing code is old and terrible.

Adam

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

Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?

[Adam Harvey]

On 22 September 2014 04:32, Derick Rethans der...@php.net wrote:
 On Sat, 20 Sep 2014, Andrea Faulds wrote:

 Perhaps I’m being unfair and overthinking things, but I wonder if it
 is really fair for people who have no karma, i.e. not contributors to
 the documentation, extensions, php-src or anything else, to have the
 ability to vote on RFCs?

 I’d never suggest people without internals karma can’t vote. I think
 doc and peck contributors are as valued as any other contributors.
 However, people with no karma whatsoever (a blank people.php.net page)
 voting irks me.

 I think people's votes should only count if they have karma to the
 section of the code that the RFC/feature/whatever relates to.

+1. I've said this plenty over the last couple of years, as IRC
regulars can attest to. Ultimately, people who actually know and
maintain the codebase should be making the final decisions.

Which is definitely not to say that we shouldn't be listening to
people outside the voting group — obviously, we should listen, and get
feedback. I just don't believe that the haziness of the current
process (we might give you a voting account if you meet mostly
undefined criteria which no two people actually agree on, which then
allows you to provide a single tick with no feedback) encourages
that, and at some point we're going to end up with a feature being
committed that is going to cause major headaches for day to day
developers.

Adam

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

Re: [PHP-DEV] Why does checkdnsrr() default to MX??

[Adam Harvey]

On 19 September 2014 02:58, Chris Wright c...@daverandom.com wrote:
 On 18 September 2014 20:29, Kris Craig kris.cr...@gmail.com wrote:
 Hey guys,

 I just spent some time troubleshooting what appeared to be a DNS issue
 before I realized that, absent the optional $type argument, checkdnsrr()
 defaults to MX.  Can anybody explain why it's defaulting to MX and not
 ANY?  It seems really counter-intuitive.

 This is a big wtf, especially since getmxrr() exists. A cursory search
 of github (not the best measure I know, but easy) reveals only a few
 cases where this function is called without the second argument, and
 every case I've found looks like they were expecting an A record, so
 this code is likely broken anyway.

 In other words, +1 to change this to something saner ASAP.

As an alternative, could we just make the type argument mandatory in
PHP 7 and start issuing E_DEPRECATED warnings if it's omitted in 5.6
or 5.7?

Adam

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

Re: [PHP-DEV] Why does checkdnsrr() default to MX??

[Adam Harvey]

On 19 September 2014 10:51, Kris Craig kris.cr...@gmail.com wrote:
 On Fri, Sep 19, 2014 at 10:24 AM, Adam Harvey ahar...@php.net wrote:
 As an alternative, could we just make the type argument mandatory in
 PHP 7 and start issuing E_DEPRECATED warnings if it's omitted in 5.6
 or 5.7?

 I like both ideas.  Adam's approach would be more inconvenient for
 developers, but it would also be less of a BC issue since merely changing
 the default could cause some existing code to fail silently as opposed to
 generating an error.  On the other hand, I can't think of any such use case
 in which checking all DNS entries instead of just MX would cause any scripts
 to break.  The only possible scenario I can think of would be if they're
 using dnsrr() to check if an MX record exists and hit a host that has an A
 record but not MX.  That would cause it to return TRUE when they're
 expecting FALSE.

I'm not a huge fan of silently making it ANY for the reason Sanford
explained elsethread — it's a potential vector for amplification
attacks. I also don't think it's unreasonable to expect developers to
know what type of record they're interested in. :)

 I'll draft an RFC when I get a chance and include both options in it.

Thanks!

Adam

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

Re: [PHP-DEV] [RFC] Implicit isset() in Shorthand Ternary Operator

[Adam Harvey]

On 16 September 2014 11:34, Andrea Faulds a...@ajf.me wrote:
 By popular demand, I’ve changed the RFC to instead propose a ?? operator, 
 after Nikita Popov generously donated a working ?? patch. In doing so, the 
 RFC is renamed “Null Coalesce Operator”.

 Please read it: https://wiki.php.net/rfc/isset_ternary

Love it! Kudos to you and Nikita.

Is it possible to chain ?? operators; ie $value = $foo ?? $bar ?? 'default'?

Adam

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

Re: [PHP-DEV] [RFC] Implicit isset() in Shorthand Ternary Operator

[Adam Harvey]

On 8 September 2014 07:56, Christoph Becker cmbecke...@gmx.de wrote:
 Am 08.09.2014 15:58, schrieb Andrea Faulds:
 We could add such an operator, perhaps with the ?? syntax. However, I
 don’t really like the idea. It’s too similar to ?: so I don’t think
 it’d be accepted, and even if it was, I’m not sure we really need
 another operator. I’d much rather just make ?: do what, IMO, is the
 right thing and what it always should have done.

 I'd rather had a shortcut for the following:

   isset($_GET['foo']) ? $_GET['foo'] : BAR

Agreed. That's what ifsetor requests have generally boiled down to
over the years, so it seems to be what the masses want.

It's what _I_ want, anyway. :)

 Of course, it is not possible to change the ?: operator to work this way
 for BC reasons, but a new operator such as ?? might make sense.

+1 on ?? — there's precedent for it, and it means we don't have to
explain why the shorthand form of an operator behaves differently to
the long form, which is just going to confuse users.

Adam

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

Re: [PHP-DEV] [RFC] Implicit isset() in Shorthand Ternary Operator

[Adam Harvey]

On 8 September 2014 17:07, Andrea Faulds a...@ajf.me wrote:

 On 8 Sep 2014, at 23:58, Adam Harvey ahar...@php.net wrote:

 +1 on ?? — there's precedent for it, and it means we don't have to
 explain why the shorthand form of an operator behaves differently to
 the long form, which is just going to confuse users.

 FWIW, it already behaves differently:

 oa-res-27-90:~ ajf$ php -r 'function foo() { echo foo\n; return true; } 
 $x = foo() ?: false;'
 foo
 oa-res-27-90:~ ajf$ php -r 'function foo() { echo foo\n; return true; } 
 $x = foo() ? foo() : false;'
 foo
 foo

You could argue whether that's unexpected behaviour or not — there is
only one foo() call in the shorthand version, after all, so it makes
intuitive sense that foo() would only be called once.

Regardless of how you feel about that, though, I don't think
increasing the amount of inconsistency between two versions of the
same operator (forget the implementation; that's how it's documented
and how it's perceived) is a good idea.

Adam

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

Re: [PHP-DEV] On BC and not being evil (Was: Re: [PHP-DEV] [RFC] Integer Semantics)

[Adam Harvey]

On 21 August 2014 08:30, Derick Rethans der...@php.net wrote:
 Can I please urge people to not take Backwards Compatibility issues so
 lightly. Please think really careful when you suggest to break Backwards
 Compatibility, it should only be considered if there is a real and
 important reason to do so. Changing binary comparison is not one of
 those, changing behaviour for everybody regarding  and  is
 not one of those, and subtle changes to what syntax means is certainly
 not one of them.

 **Don't be Evil**

+1 on everything Derick said.

I want to make one more point: if there's just one thing we learn from
other languages that have made BC-breaking, major version transitions,
it should be that library and framework authors will ultimately have
to support both versions in the same code base. Python tried using
tooling such as 2to3 to help manage the transition, but in the end the
only way Python 3 has gotten any traction is libraries supporting
both, which effectively means that library authors can only write the
subset of Python that's supported by 2 and 3.

Every time we break BC — in either of the ways Derick said — we narrow
the subset of PHP 5 and PHP 7 that's available to people writing PHP
code that has to work on both. If we narrow it too far, it'll be too
unexpressive, or too hard to use, or just plain won't do something
that they'll need, and PHP 7 will risk becoming this decade's Perl 6:
the cautionary tale for what happens when you burn all the boats.

PHP 7 is an opportunity. It needs to be one that we embrace, and take
advantage of, but most importantly one that is evolutionary and allows
our user base to come with us.

Adam

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

[PHP-DEV] Re: [STANDARDS] Re: [PHP-DEV] [RFC] Disallow multiple default blocks in a single switch statement

[Adam Harvey]

On 6 August 2014 12:32, Ferenc Kovacs tyr...@gmail.com wrote:
 On Wed, Aug 6, 2014 at 8:35 PM, Sara Golemon poll...@php.net wrote:
 
 Did we agree on that?  The lang spec was originally written to 5.6 to
 have a relatively stable target, but (in my mind at least) was meant
 to track master as we move the language forward.  Was there a
 discussion about branching the langspec repo for versions?


 maybe that was just my impression.
 I'm not sure what would be the best solution, but if we don't version the
 spec, then when we introduce BC breaks or simply new features in a new
 version which is in turn get's added to the spec, that would make the older
 php version's(from any implementation) not being compliant with the spec.
 would be nice checking out how other spec-driven languages manage this
 problem (I know that at least java has separate spec for each major
 version), but I don't think that a single spec can exists which allows
 alternative implementations to say that they comform me spec while the
 reference implementation and the spec can still change/evolve after the
 initial release.

I guess I (possibly) misinterpreted that too, which is why I changed
the original bug report to be a spec bug rather than a ZE bug. I too
was under the impression that the spec right now would document 5.6 as
it actually is (rather than being aspirational), and then future
versions would be separate documents (branches, presumably) that would
be updated as part of the RFC process when changes were made.

Adam, who has just come to the horrible realisation that this is going
to require someone to write an RFC. Dibs not me.

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

Re: [PHP-DEV] [VOTE][RFC] intdiv()

[Adam Harvey]

-1 explanation: I don't think %% is clear enough, the only sensible
syntax choice (//) is unavailable to us, and I think the utility of
having it baked into the language as an operator is pretty minimal
regardless (I coded a lot of Python for scientific research in a
previous job, and I don't think I ever used //, and you'd think that's
the place where you'd use it).

+1 on the function, though — quick searches on Ohloh and Github
suggest that there are a grand total of three open source projects
that implement a global intdiv() function. Seems safe enough.

Adam

On 29 July 2014 19:31, Andrea Faulds a...@ajf.me wrote:
 Good evening,

 The intdiv RFC is put to the vote, with separate votes for the integer 
 division operator (%%) and intdiv function, the latter as a fallback. I would 
 highly encourage you to read the discussion in the “[RFC] intdiv()” thread 
 and the whole RFC before voting.

 The vote is here: https://wiki.php.net/rfc/intdiv#vote

 It is opened today (2014-07-30) and ends 2014-08-06.

 Thanks!
 --
 Andrea Faulds
 http://ajf.me/





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


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

Re: [PHP-DEV] crypt() BC issue

[Adam Harvey]

On 16 July 2014 23:16, Tjerk Meesters tjerk.meest...@gmail.com wrote:
 On Thu, Jul 17, 2014 at 10:25 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:

 Hi Tjerk,

 On Thu, Jul 17, 2014 at 11:09 AM, Tjerk Meesters tjerk.meest...@gmail.com
  wrote:

 Why should `password_verify()` work on a hash that wasn't generated with
 `password_hash()`? The fact that it uses `crypt()` internally should not
 leak outside of its API, imho.


 password_*() is designed as crypt() wrapper and this fact is documented
 since it was released.

 Obsolete password hash is easy to verify with password_needs_rehash().
 Developers can check password database easily with password_needs_rehash().


 The documentation states that the `hash` argument to both
 `password_needs_rehash()` and `password_verify()` is:

 hash - A hash created by password_hash().

Whoa. Don't put too much stock in that — I think I made that up out of
whole cloth while trying to get _something_ into the manual for one of
the early alpha releases of 5.5, and it wasn't intended as a
restrictive statement.

 Passing a value from your own crypt() implementation may work, but that
 shouldn't be relied upon. I certainly wouldn't classify it as a problem
 that should be fixed in the password api.

The original RFC specified that both crypt() and password_hash()
hashes were accepted here, and that's probably what the documentation
should say too.

Adam

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

Re: [PHP-DEV] RFC: Expectations

[Adam Harvey]

On 22 October 2013 02:08, Derick Rethans der...@php.net wrote:
 I'm pretty convinced that expectations *without* exceptions are a good
 idea, as using assert (which is really eval) is a nasty thing that
 should be replaced, but IMO exception throwing should not be part of
 this feature.

I agree that something to replace the eval-based assert() would be
good. What if the new syntax simply respected assert_options(), and
assert_options() was extended to support an explicit ASSERT_EXCEPTION
control option (that presumably took an exception class name as its
option value)? That seems like it would provide the exception based
possibilities that some posters want while maintaining the same
assertion behaviour that users are already used to by default.

Adam, who apologises if this has been suggested before — this was a
long set of threads and I've been busy.

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

Re: [PHP-DEV] RFC: Expectations

[Adam Harvey]

On 22 October 2013 10:32, Joe Watkins pthre...@pthreads.org wrote:
 On 10/22/2013 06:20 PM, Adam Harvey wrote:
 I agree that something to replace the eval-based assert() would be
 good. What if the new syntax simply respected assert_options(), and
 assert_options() was extended to support an explicit ASSERT_EXCEPTION
 control option (that presumably took an exception class name as its
 option value)? That seems like it would provide the exception based
 possibilities that some posters want while maintaining the same
 assertion behaviour that users are already used to by default.

 I'm a bit perplexed at the need to retain any compatibility with what is a
 poor implementation ?

To be fair, I think part of the disconnect here is that I don't feel
like the current implementation is particularly poor besides the
eval-based API. I don't really want an assertion failure to throw an
exception — if I did, I'd use an assert callback or ErrorException to
do that. I want it logged so I can look at it later, and that's easily
configured with the current assertion setup.

I guess I'm wondering if there's a middle ground here, rather than
throwing the assertion baby out with the bathwater in favour of an
entirely new thing that could simply be syntax sugar sprinkled over an
existing, working implementation.

Adam

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

Re: [PHP-DEV] NEWS handling

[Adam Harvey]

On 8 October 2013 06:46, Michael Wallner m...@php.net wrote:
 I was wondering how we are supposed to handle NEWS entries when a fix
 goes into both branches, PHP-5.4 and 5.5. IIRC we used to add the BFN
 only to the lowest numbered branch, but then again that was at times
 we had mostly onle one stable release branch...

The way I've done it (and it seems like most developers are doing it
now) is to add the same entry to each stable branch as I merge
upwards, so the 5.4 and 5.5 NEWS files each end up with something
like:

- Extension:
  . Fixed bug #12345 (luggage combination is weak). (Adam)

I think the bug number really has to be in each branch for the NEWS
file to be useful — users need to be able to find out at a glance
what's been fixed from 5.5.4 to 5.5.5, for instance.

Adam

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

Re: [PHP-DEV] Locale-independent double-to-string cast

[Adam Harvey]

On 2 October 2013 10:57, Christopher Jones christopher.jo...@oracle.com wrote:
 On 10/02/2013 10:26 AM, Nikita Popov wrote:
 I'd like to change our double-to-string casting behavior to be
 locale-independent and would appreciate some opinions as to whether you
 consider this feasible.

 I'd like to see float/double casts recognize the locale's decimal
 separator.

That's an interesting idea, and arguably one that's more in line with
what PHP has been doing.

I'd be really interested to hear from people in countries where the
decimal separator is a comma, since I don't have any experience with
this myself as an Anglophone — do you run PHP in your native locale,
and if so, would it be better to always have dots, as Nikita suggests,
or support parsing numbers with commas? (Or some combination therein.)

Adam

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

Re: [PHP-DEV] HTTP supergloblas and request body/query (was: Parsing PUT data)

[Adam Harvey]

 On 02.10.2013, at 10:59, Michael Wallner m...@php.net wrote:

 Since ever people are confused by _GET and _POST superglobals,
 because, despite their name, they do not (really) depend on the
 request method.  Therefor I propose to phase out $_GET and name it
 $_QUERY and I propose to phase out $_POST and name it $_FORM (I'm not
 100% confident with the latter yet, though).

I'm not really sure people are confused, actually. There are plenty of
common gotchas that I see daily in ##php, but that isn't one of them.

I like how Alexey broke this down, so I'm going to steal it. :)

On 2 October 2013 00:17, Alexey Zakhlestin indey...@gmail.com wrote:
 1. _GET - _QUERY, _POST - _FORM

As I hinted at above, I'm -1 on this at first blush. I don't think
it's really that confusing in practice and $_GET and $_POST have a lot
of history (and muscle memory) behind them at this point.

 2. ignore request-method, trigger body-processing solely on Content-type

Definite +1 here.

 3. expose body-parsers via php-level API

+1, particularly if it's also available in userland as Alexey got
excited about. :)

Adam

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

Re: [PHP-DEV] RFC: Anonymous Classes

[Adam Harvey]

On 23 September 2013 08:03, Chris Wright daveran...@php.net wrote:
 To summarize how I think this should be handled: Serialisation results in a
 stdClass, unserialisation cannot be done because if you want it you're
 already
 Doing It WrongT.

To me, serialising successfully would indicate that PHP could
unserialise the object as it was. Since it can't, I'd prefer to just
error out at the serialize() stage.

As for the feature itself, I'm not really sold right now. The use
cases I've seen for this previously in other languages have been
situations where either a simple anonymous function or closure would
suffice, or alternatively situations where you have a big anonymous
class with lots of methods, and I think for the latter case I'd rather
promote separating those sorts of implementations into standalone
classes for readability reasons.

Adam, who isn't even pretending that he's looked at the patch yet.

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

Re: [PHP-DEV] Re: Re: PHP Crypt functions - security audit

[Adam Harvey]

On 19 September 2013 10:52, Daniel Lowrey rdlow...@gmail.com wrote:
 *I consider this a bug* I understand that it's easier to code not verifying 
 the
 peer, and the hostname may not be available when you are stacking ssl over a 
 stream.
 But file_get_contents(https://...;) is *precisely* the case that should 
 work right
 out of the box.

 ^^ This.

 Before I can fully/cleanly implement these changes we need to decide
 if PHP wants to move to a secure-by-default model for streams
 utilizing the built in encryption wrappers. Thoughts?

I think we should do this in 5.6. cURL has behaved this way for
literally years at this point (verify by default, provide a switch to
disable verification) and users seem to do just fine there. The much
improved security story outweighs the (admittedly present) BC issues
for mine.

As for the CA bundle side of things, I wonder if this is one of those
rare times where an ini setting might make sense, as opposed to actual
bundling — that would allow distros to point to their packaged bundles
without needing to patch php-src, and we could provide from-source
installation instructions easily enough to point to common distro
locations and the cURL download for users on more exotic OSes (like
Windows).

Adam

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

Re: [PHP-DEV] Re: Re: PHP Crypt functions - security audit

[Adam Harvey]

On 19 September 2013 17:31, Pierre Joye pierre@gmail.com wrote:
 On Thu, Sep 19, 2013 at 2:41 PM, Adam Harvey ahar...@php.net wrote:
 As for the CA bundle side of things, I wonder if this is one of those
 rare times where an ini setting might make sense, as opposed to actual
 bundling — that would allow distros to point to their packaged bundles
 without needing to patch php-src, and we could provide from-source
 installation instructions easily enough to point to common distro
 locations and the cURL download for users on more exotic OSes (like
 Windows).

 Windows supports that very well, with Curl for example. It can also
 uses the OS certificates database.

 For the record here, curl has this setting already:

 http://us2.php.net/manual/en/curl.configuration.php#ini.curl.cainfo

 which is around for quite some time already.

 It could be possible to share it with openssl, but back then I did not
 check it out as only curl was concerned.

Is that something cURL provides, or that we do? A (very) cursory
Google suggests that OpenSSL doesn't have support for the Windows
certificate store natively, so we'd presumably have to patch that up
(with a sensible default php.ini setting, if we went that way —
ssl.ca_bundle = win32, or something similar).

 One thing I do not remember off hand is if we actually enable cert
 validation per default with php's curl. It should be as we discussed
 that already many times.

We do. I checked before the first e-mail. :)

Adam

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

Re: [PHP-DEV] Re: Re: PHP Crypt functions - security audit

[Adam Harvey]

On 19 September 2013 17:41, Pierre Joye pierre@gmail.com wrote:
 It does when you use curl's win32 SSL support. That makes my previous
 point wrong as we do not compile it with this option but openssl (for
 cross platform compatibility reasons). But as the curl's ca file works
 just fine, everything is good.

 Would it make sense to share that option for openssl itself?

I think so, particularly if we did make peer validation the default.
Most Windows users would be happy to just use the system certificate
store, I would think, so that would be one less thing to configure
post-install.

Adam

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

Re: [PHP-DEV] [RFC] Named parameters

[Adam Harvey]

On 6 September 2013 09:39, Nikita Popov nikita@gmail.com wrote:
 The RFC and implementation are not yet complete. I mainly want to have
 feedback on the idea in general and on the Open Questions (
 https://wiki.php.net/rfc/named_params#open_questions) in particular.

Thanks for proposing this. I haven't looked at the patch yet, but I'm
all for the feature.

My thoughts on your open questions:

Syntax: I suspect this will end up having to go to a vote (classic
bikeshed), but I'm on the func('foo' = 'bar') train. :foo doesn't
make sense in a PHP context (we'd have to implement that across the
language, not just for function calls), : as a key-value separator
would only work if it was also supported in array literals, and =
feels a little wrong for this. I don't really like the unquoted
parameter names so much; it's inconsistent with array literals and
bare words as strings is something that's been discouraged for a long
time.

Variadics/splat: collecting both named and positional arguments into
one array seems reasonable to me. I think the main use case there
would be option parameters, which you'd have to validate anyway, so
positional parameters would be dealt with at that point — I don't see
separate arrays as conferring any great advantage in terms of
validating parameters, and it's no simpler conceptually.

call_user_func_array: for consistency, we might want to consider
adding an analogue function that deals with named parameters, even
though it would work via $callable(...$kwargs).

Contracts: I agree with you, basically — it would have to be an
E_STRICT or thereabouts, with the possibility of revisiting come a
hypothetical PHP 6.

Adam

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

Re: [PHP-DEV] [RFC] Named parameters

[Adam Harvey]

On 6 September 2013 12:12, Dan Ackroyd dan...@basereality.com wrote:
 If named parameters are introduced, signature validation should include
 parameter names. Throwing a fatal error (for the interface/class
 combination)
 would break backwards compatibility though. We could use some lower error
 type...

 Would it be possible to set the error level through an ini setting? Or
 disable it entirely?

I've said this before, but to reiterate it: I'd be a huge -1 on
anything that involves configurable language behaviour. It's a support
nightmare, and I'm glad those days are now mostly over.

 People who are writing new code that is aware of named parameters should
 want a fatal error for any coding mistake that violates the contract.

I'd say the odds are that those sorts of users are going to be writing
code that is required to be notice/strict clean anyway — that's
certainly been true everywhere I've worked that's had a modern
codebase.

Adam

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

Re: [PHP-DEV] [RFC] Named parameters

[Adam Harvey]

On 6 September 2013 13:01, Dan Ackroyd dan...@basereality.com wrote:
 I'd say the odds are that those sorts of users are going to be writing

 code that is required to be notice/strict clean anyway — that's
 certainly been true everywhere I've worked that's had a modern
 codebase.

 Yes, so say you have a team that:

 * currently has a code base that is notice/strict clean
 * wants to move to PHP 5.x which has named parameters
 * have code which changes the param name in extends/implements

 Unless they rewrite their code, they wouldn't be able to upgrade next
 version of PHP without losing their strict/notice cleaness. So how would you
 suggest they upgrade to the version of PHP with named parameters?

At the risk of being glib, by cleaning up their parameter names. A
team that's testing a PHP upgrade is likely capable of that, and the
strict notices would give them the needed feedback in the early stages
of testing. That's hardly a rewrite.

 Also I'm not sure that having which error level is used actually changes the
 behaviour of the language in a meaningful way. It only suppresses a
 particular warning message, which can be suppressed anyway with
 error_reporting(0).

I don't really care which level actually gets used (it could be
anywhere from E_STRICT to E_WARNING from where I sit), but I don't
think the error reporting for a particular feature should ever be
controllable separately from PHP's global error reporting. These sorts
of warnings are there to promote better practice.

Adam

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

Re: [PHP-DEV] [RFC] Argument unpacking

[Adam Harvey]

On 31 August 2013 03:21, Nikita Popov nikita@gmail.com wrote:
 This is very special use case to be hidden in library functions, I don't
 think we need to have language syntax specially directed at that, at the
 cost of making it overall more complex and hard to understand. I can see
 what add all those params at the end syntax mean. However having
 something like ($a, ...$b, $c, ...$d, $e, $f, $g, ...$h) I have no idea
 what's going on at all and what is sent where.

I can grok this, but I'd rather not have to work through it when
reading someone else's code. The likely code in current versions of
PHP using call_user_func_array() would almost certainly be clearer
here. So I think I'd prefer to disallow multiple splats in a function
invocation too.

snip
 Of course, maybe my logic is flawed because I give too much credit to
 programmers and assume that they will employ features when reasonable and
 not when hey, why don't I go put a ... in here!

At the risk of sounding even more bitter than normal, you need to
spend more time in ##php with that attitude. ;)

 Anyway, I don't think having a trailing fixed argument is *that* absurd. A
 pretty pointless example off the top of my head would be
 $this-query($query . ' LIMIT ?', ...$params, $limit), i.e. just adding
 another bound param to a set of existing ones.

 I don't really insist on allowing the trailing normal args, because I don't
 think they would be useful particularly often, but I just fail to see what
 we gain by forbidding them.

I have pretty much the same readability concern as with multiple
splats — this example is clear, but I'm not sure it's so clear with a
larger, more verbose set of arguments. This seems to require a
slightly sharper eye to me (OK, it'd be better in a fixed width
editor, admittedly):

do_something($a_long_variable, $another_long_variable,
...$hey_a_splat, $something_else, $foo, $bar)

I care less about this than multiple splats, but it's still a concern to me.

Adam, who will send another e-mail momentarily to paint some bikesheds.

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

Re: [PHP-DEV] [RFC] Argument unpacking

[Adam Harvey]

On 30 August 2013 08:23, Nikita Popov nikita@gmail.com wrote:
 The syntax it introduces looks as follows:

 $db-query($query, ...$params);

Somebody was going to do this, and it's going to be me. Sorry. We were
doing so well.

I don't like the ellipsis. I could just about deal with it for the
variadic RFC, since it's at least not worlds away from C++ (and there
are other precedents for it, as you noted), but it looks really weird
to me as the splat operator. It looks like you're hesitant to call the
function or ashamed of $params rather than unpacking something.

I know there's a symbol soup issue for by-ref variadic arguments, as
you mentioned in the RFC, but I think that's an unusual enough use
case that * is still the better option — it doesn't break the flow of
the code as much as a three character operator, and while it's no more
visually intuitive than ..., it does have the advantage of being what
Python and Ruby used.

I'm raising this in this thread because I'm more concerned about the
visual impact of it here, but obviously whatever we use as the
operator for one is what we should use for the other, assuming both
RFCs are accepted.

Adam, who is wincing as he sends this at the likely subthread that will ensue.

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

Re: [PHP-DEV] Operator precedence is undefined?

[Adam Harvey]

(Piggy-backing on Sara's e-mail, although this is more a response to
Sherif and Yasuo.)

On 19 July 2013 22:33, Sara Golemon poll...@php.net wrote:
 I never said that the compiler might magically produce differing results
 for the same input.  I said that the language's definition does not declare
 a defined behavior for such expressions with combined side effects.

This is also a classic piece of undefined behaviour in most C-like
languages — Bjarne Stroustrup lists it in his C++ FAQ, for instance:
http://www.stroustrup.com/bs_faq2.html#evaluation-order. That's not to
say that PHP necessarily has to be the same as other languages in its
family (nested ternaries, anyone?), but I don't think that PHP is
really doing anything different here that would make it well defined:
AFAIK, the only places PHP makes guarantees about the order of
evaluation with regard to binary operators is short circuiting the
boolean operators.

 As to reverting commits.  When the initial commit was made in haste during
 an active discussion, a revert is entirely appropriate and has nothing to
 do with placing one's opinion over another's.  It has to do with placing
 the process of consensus building over unilateral cowboy commits.

+1.

Adam

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

[PHP-DEV] Re: [PHP-DOC] Re: OPCache documentation

[Adam Harvey]

On 20 June 2013 14:36, Julien Pauli jpa...@php.net wrote:
 On Wed, May 15, 2013 at 3:54 PM, Julien Pauli jpa...@php.net wrote:

 Hi all,

 As you know, 5.5 final is coming soon.
 We are in RC, so mainly stabilizing stuff and preparing the final release
 for anyone to setup 5.5 on their servers.

 I see the documentation migration guide has already been commited, that's
 a good new.
 I also see that new features we ship in 5.5 are online in the
 documentation, great !

 But a crucial feature is missing doc : OPCache.

 As this feature is a very big step in PHP's life (we finally have a
 recommanded, bundled opcode cache system, and I'm very proud of this
 personnaly), I think it is crucial to have a good documentation about it.

 Has anyone started to write some doc about OPCache ?

 Another subject is APC. We have its doc on php.net, all right.
 What I would like is we patch APC doc when 5.5 final gets released, to
 clearly show our mind about it.
 That way, any people using 5.5 should be able to read in the doc that APC
 has support has been interrupted, that APC should never be used together
 with OPCache, and that OPCache is now the standard recommanded OPCode
 caching solution for 5.5, 5.4 and 5.3.

 It is crucial to communicate one this point for our users.

 Then will come the User cache debate

 Thank you.



 Up. Could we at least plan such a project ?
 5.5 is released now. I know we are still having trouble about OpCache
 particulary under Windows. I dont shadow that.
 I would just like we start thinking about writing documentation for OPCache
 features and merge them to our official documentation. If it's already
 planned by someone, just let me know ;-)

I'm working on some basic opcache documentation as we speak, since it
was pointed out on #php.doc. That said, mostly what I'm doing for now
is adapting the README in ext/opcache and documenting opcache_reset()
and opcache_invalidate() — some additional theory of operating and
setup documentation would be very welcome.

There should be something to look at in SVN in the next hour or so.

My apologies — I wrote the first draft of the migration guide in the
mid alpha stage (ie before opcache was merged) of 5.5 with the
intention of going back to flesh it out before the final release, but
time has been a bit of an issue. Turns out moving halfway across the
world is a real time sink.

Adam

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

Re: [PHP-DEV] Proposal for better UTF-8 handling

[Adam Harvey]

On 26 May 2013 21:05, Stas Malyshev smalys...@sugarcrm.com wrote:

 I agree with Nikita — I'm not against adding more Unicode/charset
 handling functions if they make sense (and I haven't looked at the
 code for this particular proposal yet), particularly if they'd be part
 of a default build, but enough water has hopefully passed under the

 Did you mean would *not* be part of the default build? Because having
 yet another way of handling utf-8 (also basing on yet another separate
 library so with potential for incompatibilities and quirks) doesn't look
 like a good idea. Having yet another PECL ext is not a big deal, but
 having yet another way by default certainly would only create confusion.

I did mean would — one issue with much of our internationalisation
code is that it's in extensions (intl, iconv, mbstring) that are
inconsistently deployed by shared hosting providers. Having some basic
conversion and string handling functions that could be available in
ext/standard might not be a bad thing.

I do agree that having yet another set of functions with their own
behaviours isn't ideal, though.

Adam

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

Re: [PHP-DEV] Proposal for better UTF-8 handling

[Adam Harvey]

On 24 May 2013 08:26, Ferenc Kovacs tyr...@gmail.com wrote:
 On Fri, May 24, 2013 at 3:09 PM, Nikita Popov nikita@gmail.com wrote:
 We already have a lot of functions for multibyte string handling. Let me
 list a few:

  * The str* functions. Most of them are safe for usage with UTF8.
 Exceptions are basically everything where you manually provide an offset,
 e.g. writing substr($str, 0, 100) is not safe. substr($str, 0, strpos($str,
 'xyz')) on the other hand is.
  * The mb* functions. They work with various encodings and usually make of
 of character offsets and lengths rather than byte offsets and lengths. They
 are not necessary most of the time, but useful for the aforementioned
 substr call with hardcoded offsets.
  * The Intl extension. This give you *real* unicode support, as in
 collations, locales, transliteration, etc.
  * The grapheme* functions which are also part of intl. The work with
 grapheme cluster offsets and lengths.

 Anyway, my point is that just adding *yet another* set of string functions
 won't solve anything, just make things even more complicated than they
 already are. I'm not strictly opposed to adding more functions if they are
 necessary, but one has to be aware of what there already is and how the new
 functions will integrate.

 Nikita


 did you just forgot the pcre functions with the /u modifier?!?!
 :P

And that's without even touching PECL. :)

I agree with Nikita — I'm not against adding more Unicode/charset
handling functions if they make sense (and I haven't looked at the
code for this particular proposal yet), particularly if they'd be part
of a default build, but enough water has hopefully passed under the
bridge since the PHP 6 days that it might be time to canvass ideas on
a less piecemeal approach to character set handling and
internationalisation for PHP 5.5+1 or PHP 5.5+2.

Adam

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

Re: [PHP-DEV] Re: hash_pbkdf2 vs openssl_pbkdf2

[Adam Harvey]

On 23 May 2013 13:31, Nikita Popov nikita@gmail.com wrote:
 On Sat, May 18, 2013 at 11:48 AM, Nikita Popov nikita@gmail.com wrote:

 Hi internals!

 I just noticed that we added the PBKDF2 algorithm two times in PHP 5.5.
 Once in the hash extension, once in the OpenSSL extension.

 The hash_pbkdf2 function was added via this RFC:
 https://wiki.php.net/rfc/hash_pbkdf2

 The openssl_pbkdf2 function probably was not noticed at that time because
 it was just commited, but not mentioned anywhere else (NEWS, UPGRADING,
 etc). Only saw it in vrana's documentation updates just now. The relevant
 commit is here: https://github.com/php/php-src/commit/f4847ef

 It would be nice if we could have only one of those functions. I'm
 currently tending towards the hash_ variant because of the commit message
 of the openssl_ function:

  No easy way to put these in the hash extension since we don't really
 support optional
  parameters to certain algorithms. Implemented in openssl for now since
 it has it already
  and is pretty stable.
 
  Only SHA1 is confirmed to work as an algorithm but openssl has a
 parameter so it can be
  changed in the future.

 It seems that the author already would have preferred it in the hash
 extension and that the openssl variant only works with sha1 (or was only
 tested with it? not sure).

 Nikita


 No more opinions? It would be nice to have this resolved before 5.5,
 otherwise there will be no way back.

I'm not really convinced this is a problem in practice — hash_pbkdf2()
is likely to be the commonly used one because it doesn't have the
OpenSSL dependency, but it probably doesn't hurt to have the ability
to also call OpenSSL's independent implementation (say, if a bug is
found in one or the other).

Adam

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

Re: [PHP-DEV] Re: hash_pbkdf2 vs openssl_pbkdf2

[Adam Harvey]

On 23 May 2013 14:11, Nikita Popov nikita@gmail.com wrote:
 If a bug is found we fix it. Proving several implementations of the same
 thing to account for potential bugs isn't a good idea imho.

It's not a very good example, I admit, but my point is that it's not
as though they're actually the same code underneath.

 If two functions for the same thing exist people need to wonder about which
 one of them should be used, and in the worst case decide to use a pattern
 like if function1 exists call function1, if function2 exists call
 function2, etc. Just like nowadays to generate a random string you usually
 check something like four of five different functions. I think it's
 preferable to have one and only one function in a default-enabled extension.

I think that horse bolted about a decade ago. Assuming the OpenSSL
version does actually work properly, I don't see why it's an issue.

Adam

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

Re: [PHP-DEV] Bug #64910: Line number of $e = new Exception vs. line number of throw $e

[Adam Harvey]

On 23 May 2013 17:14, Stas Malyshev smalys...@sugarcrm.com wrote:
 Hi!

 the code does throw new, it is always useful. So how you would
 propose
 to solve this?

 rethrow $e;

 Yes, this is definitely an option, but requires a new keyword.

We could use a C++ style throw; as an implicit rethrow.

Adam

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

Re: [PHP-DEV] idea: implement a Comparable interface

[Adam Harvey]

On 7 May 2013 09:17, Thomas Anderson zeln...@gmail.com wrote:
 It'd be nice if, when doing $objA  $objB, that that'd invoke
 $objA-__compareTo($objB) or something, much like Java's Comparable
 interface.

I wrote https://wiki.php.net/rfc/comparable a couple of years ago —
there's a patch there that would probably still apply without too much
work to master. About the only difference was that I didn't double
underscore the magic method (in line with both Java and PHP interfaces
like Countable).

I ended up withdrawing it because the response at the time was
somewhere between meh and outright hostility; I didn't see much
point devoting time to something that was going to fail a vote
regardless. It could be dusted off and reproposed for 5.6 if there was
enough interest, but my guess is that it'd still be an uphill battle
(even though some internal classes, most notably DateTime, do exactly
this).

Adam

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

Re: [PHP-DEV] idea: letting the line number and file name be set via user_error

[Adam Harvey]

On 7 May 2013 12:24, Thomas Anderson zeln...@gmail.com wrote:
 I thought half the point of OOP was to abstract away the internals and as
 is the error messages don't make much sense unless you *do* consider the
 internals.

 Like let's say you have a bignum library and you're doing
 $fifteen-divide($zero) on line 5 of test.php. Seems to me that it'd be
 more useful to say error: division by zero on line 5 of test.php instead
 of line line xx of file yy. It's like...

 ooh - let me try to find where I'm doing division by zero. Let me to line
 xx of file yy that I didn't even write and don't know a thing about. ok...
 so it looks like that's in the private _helper_function(). And
 _helper_function() is called by 15x other public functions. I give up!

Sure, but in practice, that's why most development environments
provide backtraces on error or uncaught exception, whether through
something like XDebug or via a call to debug_print_backtrace() in the
error/exception handler. That gives you both the specific information
you want (the last file and line of non-library code that called into
the erroneous function(s)) and all the additional context you might
need.

As Ferenc said, I also don't understand how you'd get the fake file
and line numbers for the trigger_error() call without guesswork or
going back up through the backtrace anyway, which is something that
doesn't belong in non-handler code, IMO.

 As an end user of a library you shouldn't have to actually look into that
 library if you're the one who's not properly handling something.

I agree, but this is already a solved problem in PHP. All the tools
needed are there.

Adam

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