ecca Black “Friday” music video is clearly
> > a kind of rickroll. :-)
>
Indeed. It was meant as a joke, not to deceive anyone. I'll take it down :)
>
> That commit was done by Leigh , which was active on
> internals in 2016. Perhaps we should ask them to remove it?
>
> cheers,
> Derick
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
On Wed, 16 Aug 2017 at 20:13 Solar Designer wrote:
> Also, why even bother to support ranges beyond 32-bit? Sounds like a
> misfeature to me, considering it won't(?) be universally available on
> all PHP builds anyway (not on 32-bit ones, right?) and thus shouldn't(?)
> be relied upon by applica
On 27 January 2017 at 14:30, Lauri Kenttä wrote:
>> This needs to be thought of as 2^32 possible _streams_ with a period
>> of (2^19937)−1. Offset within the stream is as important as the stream
>> variation itself.
>
> This is not true. There is one stream of period (2^19937)−1, and
> the initial
On 27 January 2017 at 02:52, Yasuo Ohgaki wrote:
> Since mt_rand is predictable PRNG, there is possibility to be known to
> attackers always.
>
> What I would like to change is
>
> - there is only 2^32 initial states
This needs to be thought of as 2^32 possible _streams_ with a period
of (2^1993
On Sat, 21 Jan 2017 at 14:41 Niklas Keller wrote:
> Anyway, the "issue" with mt_rand is not the seed being predictable but the
> internal state being recoverable from the output. But mt_rand is
> predictable by design, so why should we even seed it with a CSPRNG by
> default?
>
>
> For the record
On 19 January 2017 at 11:46, Yasuo Ohgaki wrote:
> How many of us are willing to allow very weak mt_rand fallback?
> This could be RFC vote option, if there are few.
Everyone who cares about stability.
I agree, if you want to introduce breaking changes, this needs to go to RFC.
Therefore the si
On 19 January 2017 at 01:10, Yasuo Ohgaki wrote:
>
> Thank you. I have to be able to modify patch, so I'll fetch your change to
> my repo
> and make PR. BTW, I don't think we have to care for failing CSPRNG. If it
> failed,
> application should fail properly, i.e. should terminate process/code.
>
On 18 January 2017 at 16:06, Lauri Kenttä wrote:
>
> If it's not acceptable to randomize the whole state, I'd recommend using
> php_random_int_silent() to generate a single seed. This would be easy to
> implement by simply changing GENERATE_SEED() into a function which first
> tries php_random_int
On Wed, 18 Jan 2017 at 06:05 Yasuo Ohgaki wrote:
> It could be. I haven't read and research MT rand initialization code
> carefully yet.
I have, it stretches 4 bytes of seed material into 624 * 4 bytes of
material. There are only 2^32 possible initial states from direct seeding.
After the stat
On Tue, 17 Jan 2017 at 22:49 Sara Golemon wrote:
> Voting has opened on: https://wiki.php.net/rfc/hash-context.as-resource
>
> Voting will remain open for two weeks and will close on 31 Jan, 2017
> at 23:59:59 UTC
>
> -Sara
>
Thanks for the work on this.
I've voted for frozen behaviour because
On 16 January 2017 at 07:04, Yasuo Ohgaki wrote:
> Hi all,
>
> Since I was about to improve uniqid()'s entropy by replacing
> php_combined_lcg() to php_random_int(), I spent time to check other places
> that could be a problem.
>
> mt_rand()'s is seeded as follows by default.
>
> ext/standard/php_
On Fri, 13 Jan 2017 at 09:35 Niklas Keller wrote:
> Hi Anatol,
>
> Do you think we should merge hrtime into core or add a simple function just
> like microtime() to ext/standard?
>
> Regards, Niklas
>
It would be great if it could be a simple function, however it is going to
be difficult to prod
way how the proposed patch works.
>
> Thanks. Dmitry.
>
>
> ____
> From: Leigh
> Sent: Thursday, February 25, 2016 18:20
> To: Dmitry Stogov
> Cc: Nikita Popov; internals@lists.php.net; Hynek Bartoš
> Subject: Re: [PHP-DEV] Fw: unpa
upload
the release tarball.
Cheers,
Leigh
On Mon, 12 Dec 2016, 00:52 Ferenc Kovacs, wrote:
>
> On Wed, Oct 19, 2016 at 7:44 PM, Leigh wrote:
>
>
> On Wed, 5 Oct 2016 at 20:11 Derick Rethans wrote:
>
> It should be migrated properly, and also to GIT.
>
>
> H
On Sat, 5 Nov 2016 at 19:13 Stanislav Malyshev wrote:
> Hi!
>
> > On 24/10/2016 07:16, Stanislav Malyshev wrote:
> >> c. Get some specific people to volunteer to review patches in security
> >> repo regularly - how? Any takers?
> >
> > I'd be happy to help with reviewing and also setting up a pri
7;s extra volunteers that you need, I would also be happy to help
out where I can, investigating reported issues, writing and reviewing
patches.
* I have a provable interest in security
* I've submitted security issues (to PHP and other projects) in the past
* I have worked on security features
houghts and opinions?
Cheers,
Leigh.
onally. I don't know who else can do this :)
Cheers,
Leigh.
On 11 October 2016 at 10:49, Craig Duncan wrote:
> I've updated the RFC now to take the deprecation route, and included
> counting scalars:
>
> https://wiki.php.net/rfc/counting_non_countables
>
> The only remaining issue is what to do about handling *count(null)*
> I think this should be deprecat
On 6 October 2016 at 13:35, Ferenc Kovacs wrote:
>
>
> On Thu, Oct 6, 2016 at 12:12 PM, Jakub Zelenka wrote:
>>
>> Hi,
>>
>> On Tue, Oct 4, 2016 at 5:58 PM, Leigh wrote:
>>
>> > Hello list,
>> >
>> > It is my intention to create
On 6 October 2016 at 11:12, Jakub Zelenka wrote:
> Hi,
>
> On Tue, Oct 4, 2016 at 5:58 PM, Leigh wrote:
>>
>> Hello list,
>>
>> It is my intention to create a new PECL package for ext/mcrypt, so
>> that it can be removed from master as per the RFC
>
On 5 October 2016 at 20:11, Derick Rethans wrote:
> It should be migrated properly, and also to GIT. I prefer that it is
> released with my username as "lead", as I wrote a big deal of it.
>
> cheers,
> Derick
I'm not sure what you mean by "properly", what steps do you think I'll
miss out? (My in
The list was missed off of Yasuo's replies to me, replying including the
list
On Wed, 5 Oct 2016 at 01:07 Yasuo Ohgaki wrote:
> Hi Leigh,
>
> On Tue, Oct 4, 2016 at 7:06 PM, Leigh wrote:
> > Since we want to preserve BC
> >
> > entropy = random_int(0, )
.
Any objections/comments? If not I'll apply for my PECL account in the
next few days.
Cheers,
Leigh.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 4 October 2016 at 10:32, Craig Duncan wrote:
> Hi everybody
>
> I'd like to propose the introduction of warning when counting objects that
> can't be counted.
>
> The default behaviour is to return 1 for these objects, which can be
> misleading and hide bugs when attempting to count iterable ob
On 4 October 2016 at 02:39, Yasuo Ohgaki wrote:
> Hi Leigh,
>
> On Mon, Oct 3, 2016 at 9:06 PM, Leigh wrote:
>> I'm curious, did you consider using random_int? It already handles
>> biasing, and you can reduce the repeated calls to random_bytes.
>
> Yes. It
On 2 October 2016 at 21:03, Yasuo Ohgaki wrote:
> Hi all,
>
> On Mon, Oct 3, 2016 at 3:56 AM, Yasuo Ohgaki wrote:
>> Besides improving "more entropy" the default and data, I prepared
>> fully compatible patch to simplify discussion.
>>
>> https://gist.github.com/anonymous/fb615df325d559fa806a2650
On Sun, 25 Sep 2016 at 06:29 Pierre Joye wrote:
> Also this behavior is clearly documented:
>
> http://th1.php.net/manual/en/function.get-class.php
>
> "If object is omitted when inside a class, the name of that class is
> returned."
>
> I am opposed to break BC because we change our mind about h
On Mon, 5 Sep 2016 at 10:39 Nicolas Grekas wrote:
> Hello,
>
> It looks like we miss a way to check by reflection if a function/method has
> strict types enabled or not.
>
> We'd need to do this in Symfony to generate a file with concatenated
> classes, but split "declare_strict=1" classes out so
On Fri, 2 Sep 2016 at 20:33 Davey Shafik wrote:
>
> I believe that pickle solves the issues with regards to pecl, and have run
> the idea passed Jordi and Pierre. Both are fine with this RFC. :)
>
> I understand that adding in composer/pickle is just setting us up for
> having a future "Deprecate
On 2 September 2016 at 16:18, Davey Shafik wrote:
> I would still be OK adding this in RC2, TBH. I didn't realize it was missed,
> and it's something we _need_ to do.
>
> - Davey
Actually, my apologies. I appear to have been living in the future and
was expecting mcrypt to have been removed this
On 22 March 2016 at 17:00, Scott Arciszewski wrote:
> Hi all,
>
> https://wiki.php.net/rfc/mcrypt-viking-funeral
>
> The tally of closing (2016-03-22T17:00:00) is 23 Yes, 6 No. This is a 79.3%
> favorable response, which exceeds the 2/3 majority by a significant margin.
>
> Thanks to everyone who
On Wed, 10 Aug 2016 at 10:15 Yasuo Ohgaki wrote:
> Hi all,
>
> This is RFC for adding session_create_id() function.
>
> Session ID string uses special binary to string conversion. Users
> should write lengthy and slow code to have the same session ID string
> as session module does.
I disagree,
On Wed, 10 Aug 2016 at 14:19 Tom Worster wrote:
> Your fix seems fine for rand() but less so for mt_rand().
>
> Applying this fix will break much less mt_rand()-using code than not
> applying it will break rand()-using code. From that point of view,
> applying it is the better choice.
>
> Otoh, i
Hi all,
There has been an unforeseen break with rand() when the minimum value is
greater than the maximum.
Prior to 7.1 rand() would happily accept backwards parameters and return a
value, however in the 7.1 branch it now emits a warning and returns false.
I've preemptively committed a fix to al
On Thu, 7 Jul 2016 at 11:39 Leigh wrote:
> As the discussion thread has been quiet for a while, moving this RFC to
> voting.
>
> https://wiki.php.net/rfc/rng_fixes
>
> https://github.com/php/php-src/pull/1986
Votes are now closed. Results as follows:
* 19-5 - Fix mt_rand() i
On Sat, 9 Jul 2016 at 10:16 Christoph Becker wrote:
>
> Assuming that "Make array_rand() more efficient" is indeed only about
> performance (and not about fixes for the broken implementation), it
> wouldn't be a bug fix, but as array_rand()'s behavior would change
> anyway as noted by the RFC, it
On Sat, 9 Jul 2016 at 09:49 Pierre Joye wrote:
>
> I am sorry but this PR possibly breaks BC and cases have been clearly
> explained how and why. Asking to show production code publically is not
> something that you should request.
>
> I can write a sample app to show you how but given the expla
On Sat, 9 Jul 2016 at 08:48 Pierre Joye wrote:
> So, I voted no then as it is clear that you do not see a problem to
> break codes without a single warning or time to adapt before.
>
> The other sections are fine and voted yes.
>
For the part where you voted no. Still nobody has presented (publi
On 7 July 2016 at 21:33, Dan Ackroyd wrote:
>> I think we need to drop the concerns about exposing "RNG state".
>>
>> If these are weak RNGs on your system, YOUR SYSTEM is broken.
>
> Telling people that their system is broken isn't going to be
> comforting to the people it happens to.
Of course
On 7 July 2016 at 13:39, Pierre Joye wrote:
> Hi
>
> Looks good but missing an option to choose the default mode.
>
> I would choose BC as default at least for one release (7.1).
It's been that way since 5.2.1, I think it's had enough releases already :)
--
PHP Internals - PHP Runtime Developm
As the discussion thread has been quiet for a while, moving this RFC to voting.
https://wiki.php.net/rfc/rng_fixes
https://github.com/php/php-src/pull/1986
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 6 July 2016 at 22:30, Yasuo Ohgaki wrote:
> php_session_create_id() may return NULL. It's an usual error. Session
> module supports session ID creation save handler which may return
> anything valid for the type.
>
> Session module tries to call php_session_create_id() several
> places/times. I
On Wed, 6 Jul 2016 at 13:10 Christoph Becker wrote:
>
> Yes, I am aware that the patch uses php_random_bytes(), but what happens
> when it fails, in which case php_session_create_id() returns null[1]?
> Would it be impossible to use a session in this case?
>
> [1]
> <
> https://github.com/php/php
On 5 July 2016 at 04:02, Pierre Joye wrote:
> We can argue about the provided pnrng being CS but it is not php's job to
> decide.
I think we need to drop the concerns about exposing "RNG state".
A reminder of what php_random_bytes looks at (in order):
* CryptGenRandom on Windows
* arc4random_buf
Actually decided to post so
On Sat, 2 Jul 2016 at 09:16 Leigh wrote:
> On Sat, 2 Jul 2016 at 08:36 Yasuo Ohgaki wrote:
>
>> Hi all,
>>
>> Currently session module uses obsolete MD5 for session ID. With
>> CSPRNG, hashing is redundant and needless. It adds
On Sat, 2 Jul 2016 at 08:36 Yasuo Ohgaki wrote:
> Hi all,
>
> Currently session module uses obsolete MD5 for session ID. With
> CSPRNG, hashing is redundant and needless. It adds hash module
> dependency and inefficient (There is no reason to use hash for CSPRNG
> generated bytes).
>
> This propo
27;ll have an implementation ready for review by the end of the week.
On 16 June 2016 at 19:54, Leigh wrote:
> RFC updated to include:
> * A note about mt_rand()s poor performance
> * Separate votes for proposals so we can at least get the security fixes
> through
> * Updated vote f
I think I've caught up on everything discussed now.
One thing I would like to point out, when people have searched for
"legitimate uses" of mt_rand(), you should have been looking for
legitimate uses of mt_srand() - this is the functionality that will be
broken.
On 16 June 2016 at 03:21, Pierre J
RFC updated to include:
* A note about mt_rand()s poor performance
* Separate votes for proposals so we can at least get the security fixes
through
* Updated vote from 50% to 2/3 as it does cause a BC issue.
I should also state that mt_rand is easily implementable in userland, so
the correct/legac
On Wed, 15 Jun 2016 at 14:05 Jordi Boggiano wrote:
> Just a thought here, if the goal is to provide a better interface,
> wouldn't it be better to use OO for this? Not because OO is better, but
> because it would avoid having problems if two mt_rand-using pieces of
> code are executed concurrentl
On Wed, 15 Jun 2016 at 00:08 Tom Worster wrote:
> On 6/14/16 12:46 PM, Leigh wrote:
>
> > The RFC can be found here: https://wiki.php.net/rfc/rng_fixes
>
> Hi Leigh,
>
> Thanks for putting this together. I am strongly pro on two points and
> moderately contra o
On Tue, 14 Jun 2016 at 20:56 Davey Shafik wrote:
>
> I think as this is a BC break it should require the 2/3 majority. I do
> support fixing the RNGs though.
>
Sure if there's a consensus on that, I have no problem with it.
Have you done any checks on GitHub etc to see how widespread this usage
On Mon, 13 Jun 2016 at 22:30 Matthew Browne wrote:
> Hi,
> What is the proper way to express support for an item that's not an
> official part of an RFC but is listed as an idea for future
> consideration? Specifically I wanted to give my "+1" for covariant
> return types which are mentioned in p
On Tue, 14 Jun 2016 at 19:14 Christoph Becker wrote:
>
> In my opinion, we need at least one random function which yields
> reproducible values.
>
> --
> Christoph M. Becker
>
Hi Christoph,
Even with the proposed changes both functions will still be capable of
reproducible sequences, just diffe
On Tue, 14 Jun 2016 at 18:45 Fleshgrinder wrote:
> Why do we need so many functions to get a random int anyways if we now
> have random_int()? I would like to see all of them deprecated and
> removed in PHP 8.0.
Lets see if others support this option. (I'm not even sure I do right now)
> I do
e but I
have overlooked, please let me know so I can get them included.
Regards,
Leigh.
On Sun, 24 Apr 2016 at 01:25 Davey Shafik wrote:
> Hi Pierrick,
>
> This should be in master for 7.1, alongside my RFC'ed patch for server push
> support.
I don't see why the additional constants that don't have a direct
dependency on your server push patch can't be committed to 7.0 as well. Th
On 25 February 2016 at 13:02, Dmitry Stogov wrote:
>
> I've just got to know about possible usage of "@" in unpack(), but it seems
> doesn't work at all
>
> $ sapi/cli/php -r 'var_dump(unpack("@0l", "\x01\x00\x00\x00")); '
> array(0) {
> }
>
> Do I use it properly?
>
> Thanks. Dmitry.
>
As Nikita
I performed a similar test yesterday:
https://www.reddit.com/r/lolphp/comments/46fxi8/typofixing_commit_in_mersenne_twister_rng_code_is/d05zwgg
There is some discussion happening on the PR:
https://github.com/php/php-src/pull/1681
On Sat, 20 Feb 2016 at 04:04 Yasuo Ohgaki wrote:
> Hi all,
>
> O
On 19 January 2016 at 02:20, Andrea Faulds wrote:
> After considering how to implement this at the opcode level, I've decided
> again that it's not worth it. Mixing keyed and unkeyed elements is not only
> an implementation nuisance (it's not necessarily hard, but it makes things
> more complicate
On 18 January 2016 at 12:35, Lester Caine wrote:
> > Hi!
> >
> > I found the idea convincing from the first read, but maybe it's just my
> > mind's assumptions about list() that I dislike the resulting syntax,
> > yet, it seems to be the logical choice.
> >
> > So, maybe I'm just trying to say, t
On 18 January 2016 at 12:22, Lester Caine wrote:
>
> My main need would be hexadecimal code
> which is not covered, so I still need the alternate hacks anyway.
>
Hex is covered, see the first examples in the "Proposal" section
On Mon, 4 Jan 2016 at 21:07 Anthony Ferrara wrote:
> Hey all,
>
> 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
>
> Let me know what you think or if there are any
On Thu, 26 Nov 2015 at 17:25 Nikita Popov wrote:
> This will throw a fatal error if the number of
> collisions during an insertion operation exceed a certain threshold.
>
To me this feels like it's just moving a DoS vector from one place to
another.
As Niklas already pointed out, he is directly
On 23 November 2015 at 21:10, Anatol Belski wrote:
> a) release on 26th including all known bug fixes
> b) do RC8, assume there are no bugs, so target 10th for RTM
> c) do RC8, release on 3rd, expect there are no bugs come in
> d) continue issuing release candidates till it's stable enough (needs
On 9 November 2015 at 15:27, Steven Hilder
>
>
> So, I prepared a patch for `get_class()` and `ReflectionClass::getName()`,
> which in my view should behave the same way as `var_dump()` etc., but I've
> now realised that ignoring the unique suffix from the class name will break
> functionality that
On 9 November 2015 at 16:42, Niklas Keller wrote:
>
> Having the path info is quite useful for debugging purposes.
>
> Regards, Niklas
>
It is, but it will always still be available from
ReflectionClass::getFileName()
On 5 November 2015 at 14:59, Rowan Collins wrote:
>
> PHP uses null bytes quite a lot to produce deliberately illegal
> identifiers. For instance the old eval-like create_function() [e.g.
> https://3v4l.org/hqHjh] and the serialization of private members [e.g.
> https://3v4l.org/R6Y6k]
>
> In thi
On 5 November 2015 at 14:21, Niklas Keller wrote:
> Hello,
>
> I discovered today that anonymous class names contain a null byte right
> after "class@anonymous". I don't think class names should contain
> non-printable characters.
>
> How about removing that null byte?
>
> https://3v4l.org/QUKpV
On 2 November 2015 at 09:25, Rowan Collins wrote:
> Andrea Faulds wrote on 01/11/2015 19:35:
>
>> I recently wished PHP had this feature when trying to implement the
>> Khronos Group Typed Arrays specification in PHP, which requires sharing
>> certain data between unrelated (inheritance-wise) cla
On 1 November 2015 at 16:07, Tom Worster wrote:
>
> I don't have one.
>
> But if I may ask, I'm curious, as always: What happens in the case that
> php_random_bytes() fails?
>
> Tom
>
That's a good point.
session_start() would throw the exception generated by php_random_bytes()
letting you know
introduce a new setting to control session id length,
perhaps overridden if session.hash_function is non-default. We have a year
to play with the details.
I'd like to hear if there are any strong objections to this proposal.
Cheers,
Leigh.
On 29 October 2015 at 02:57, guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:
> I wonder what would be necessary to make this patch possible, if there's
> any interest to move this forward and potentially target it for 7.1
> release.
>
> I'm still interested in this, and willing to he
On 28 October 2015 at 09:51, Anatol Belski wrote:
> Yeah, I was only talking about those two OS versions that are known for
> sure to have proper implementations. Even that is a smaller community than
> fe Linux, IMHO no reason to handicap users, especially as the corresponding
> codes are presen
Hi Anatol,
On 26 October 2015 at 21:58, Anatol Belski wrote:
> Which discussions do you mean, could you please link to them? The one I
> remember right now is https://github.com/php/php-src/pull/1513 , but
> there's actually no obvious conclusion. Removing arc4random is quite a
> radical move, b
On Wed, 30 Sep 2015 17:15 Scott Arciszewski wrote:
This is probably answerable by a quick yes/no and shouldn't need a ton
of bikeshedding, but if that happens anyway I apologize in advance.
I think random_bytes() and random_int() are great; they provide a
much-needed building block in PHP 7.0. H
On Thu, 6 Aug 2015 00:55 Scott Arciszewski wrote:
All,
I'd like to move the conversation towards a decision regarding PRs
1397 and 1398. These decisions are blocking random_compat as well as a
security enhancement to random_bytes (merge conflicts are *the
worst*).
Here's a quick recap
Argument
On Mon, 3 Aug 2015 at 21:54 Scott Arciszewski wrote:
> Hi,
>
> I would like to make it easier for PHP developers to implement
> cryptography features in their applications. I intend to work on some
> of these ideas and submit them for inclusion in PHP 7.1.
>
> Some of these might be familiar to s
;s a huge bonus that one of the RMs has this focus. I
expect a large amount of "casual" testing leading up to GA will be done by
people who just want to download on their desktop and try things, and
quality Windows builds will help a lot.
Many thanks for nominating yourself.
Cheers,
Leigh.
Hi all,
Voting has now closed on this RFC. The feature has been accepted for PHP 7
with votes of 41 - 0.
Thanks to all who participated in the discussion and gave feedback.
Regards,
Leigh.
On 22 March 2015 at 13:33, Yannick Komotir wrote:
> Hi,
>
> I am sorry if I am wrong but why it is not people that started php 7/ng
> project ? Dmitry, Nikita or Xichen ?
>
Personal opinion: I'd prefer all of these people had more time to work on
code, and didn't have to worry about RM duties :)
On 22 March 2015 at 08:54, Patrick Schaaf wrote:
>
> Okay, that's easier to implement and probably sufficient, if everybody
> play nice. Or, another idea and maybe a lot less work to implement: all
> active release managers could have a "want a vote" button on pending RFC
> pages.
>
+1 on RM sign
On 21 March 2015 at 12:13, Georges.L wrote:
> Hi php internals,
>
> After some long and deep research i finally decided to write my first RFC
> about a feature i'd be interested to be improved in the php core: *Nested
> enclosing returns*
>
>
> The main purpose, as the title say, is to have the p
On 22 March 2015 at 07:00, Patrick Schaaf wrote:
>
> Hmm. Is that really the line to be drawn? An RFC, by itself, provides a
> good point to spell out a change clearly, and anchor it for reference in
> discussion. Discussion on internals itself cannot provide that, it is too
> scattered, and POC c
On 22 March 2015 at 07:49, Pierre Joye wrote:
>
> From A RM point of view, I agree with other here, I could not think of
> a better person than you as one of the RMs. You did and still do a
> fantastic job, keeping things up and running, awesome communications,
> etc. As a 2nd RM, I would like som
nd RM?
Cheers,
Leigh.
On 21 March 2015 at 12:30, Peter Cowburn wrote:
> On 21 March 2015 at 08:14, Xinchen Hui wrote:
>
> > Hey:
> >
> > On Fri, Mar 20, 2015 at 9:14 PM, Xinchen Hui wrote:
> > > Hey:
> > >
> > > On Fri, Mar 20, 2015 at 7:53 PM, Alain Williams
> > wrote:
> > >> On Fri, Mar 20, 2015 at 10:46:58PM +11
On Mar 20, 2015 4:00 PM, "Alex Bowers" wrote:
>>
>> IMHO, stick to offsets in the first instance, this is a slice notation,
first order of business is to make it behave like array_slice (+on
strings). Assoc key based slicing feels pretty wrong to me at this point.
>
>
> I have to agree, we are get
On Mar 20, 2015 2:59 PM, "Alex Bowers" wrote:
>
> >
> > So $dictionary['elephant':'snake'] returns all elements with keys which
> > sort lexically between 'elephant' and 'snake', regardless of whether the
> > array is sorted.
>
>
> Makes sense to me.
>
> Alternatively, a key-based slice could look
On Mar 20, 2015 12:33 PM, "Alex Bowers" wrote:
>
> We also need to consider then the possibility of setting data by position.
>
> What should $array[@1:3] = [1,2,3] do?
>
> Should it overwrite the values there, and append any that don't exist, or
> should it be a parse error?
I'd say overwrite/r
On Mar 20, 2015 11:40 AM, "Alex Bowers" wrote:
>>
>> I've tried implementing python style slice on both strings and arrays in
>>
>> the past (I don't seem to have an existing branch with it in any more
>> though it seems). The biggest problems I hit were regarding the syntax,
the
>> functionality
On 20 March 2015 at 10:38, Leigh wrote:
>
> I've tried implementing python style slice on both strings and arrays in
> the past (I don't seem to have an existing branch with it in any more
> though it seems). The biggest problems I hit were regarding the syntax, the
> fu
On 19 March 2015 at 21:03, Larry Garfield wrote:
> Variations of this proposal have been discussed many times. I don't
> recall what the pushback was but it's worth your time to check the archives
> to see what the objections were and if you can address them, and/or if the
> new engine in PHP 7
On 17 March 2015 at 08:37, Lester Caine wrote:
> To help towards that end, can someone who understands what is wanted
> from the weak type hint mode actually produce a summary of that as it is
> very difficult to extract just what has now been agreed for that area of
> type hinting. A base that c
On 17 March 2015 at 07:08, Leigh wrote:
>
> I agree, mixed seems to serve no purpose (just don't hint the parameter,
> same result). Resource is something we're hopefully going to phase out over
> time as they get replaced with objects (like Nikita already did with GMP
On 16 March 2015 at 23:37, Dan Ackroyd wrote:
>
> In particular the keywords 'Resource' and 'mixed' seem to have limited
> need to be reserved. I don't believe there has been any suggestion
> that either of these would actually be used as types for PHP 7.x. So
> making them be unusable seems to be
On 16 March 2015 at 04:58, Levi Morrison wrote:
> Dear Internals,
>
> I am tentatively opening the vote on this RFC:
> https://wiki.php.net/rfc/reserve_more_types_in_php_7
>
> It's a bit tentative because I would prefer to wait until the vote on
> Anthony's RFC closes tomorrow as there is some ov
On 16 March 2015 at 08:04, Lester Caine wrote:
>
> Some of this Syntactic sugar would in the past have been developed in
> PEAR, but the support for 'userland' solutions via that path seems to
> have lost favour, with even the suggestion that PEAR should be dropped?
> Perhaps if PEAR contained exa
On 15 March 2015 at 22:56, Stanislav Malyshev wrote:
>
> if
> running PRNG for "too long" is dangerous, wouldn't we already have much
> more serious problem with encryption routines based on them which
> basically do it all the time?
Indeed we would, it's the kind of issue that would get solved
1 - 100 of 338 matches
Mail list logo
