Le 06/02/2017 à 18:21, Fleshgrinder a écrit :
> Hey guys! :)
>
> First: I like namespaces in Core but here me out!
>
> https://wiki.php.net/rfc/libsodium
I think the Sodium RFC vote is not about namespace but rather about
breaking everything which already use the pecl extension.
This extension
Hi!
> New classes within 7.2 (e.g. \HashContext) to be moved without concern
> for BC (e.g. \php\Hash\HashContext)
>
> Older classes (e.g. \RecursiveIteratorIterator) to be moved AND
> ALIASED FOR BC (e.g. \php\SPL\Iterator\RecursiveIteratorIterator)
Do we really need this? I mean, it's not very
Hi!
> I'm strongly against use of the PHP namespace as a blanket namespace for
> bundled PHP extensions. The PHP namespace should be used only for
> functionality that is actually in some way related to PHP. For example, the
> php-ast extension could reasonably be namespaced as php\ast, as it prov
Results for project PHP master, build date 2017-02-06 14:02:42-08:00
commit: 31332d0
previous commit:795a4c1
revision date: 2017-02-06 01:47:09+01:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
On Mon, Feb 6, 2017 at 3:47 PM, Nikita Popov wrote:
> I'm strongly against use of the PHP namespace as a blanket namespace for
> bundled PHP extensions. The PHP namespace should be used only for
> functionality that is actually in some way related to PHP. For example, the
> php-ast extension could
Idea with PHP prefix is quite interesting, but as Nikita said only for PHP
related features.
There is one missing thing in those proposals.
Let's make PHP great again! Let it be `PHP\` prefix :)
To be camel or not to be? - solved!
2017-02-06 22:01 GMT+01:00 Fleshgrinder :
> On 2/6/2017 9:47 PM, N
On 2/6/2017 9:47 PM, Nikita Popov wrote:
> I'm strongly against use of the PHP namespace as a blanket namespace
> for bundled PHP extensions. The PHP namespace should be used only
> for functionality that is actually in some way related to PHP. For
> example, the php-ast extension could reasonabl
On 2/6/2017 9:27 PM, Sara Golemon wrote:
> I've been having this same thought lately since looking at the sodium
> RFC. Here are my thoughts, centered on the goal of having classes
> (and maybe functions?) in a \php\{extname}\ namespace hierarchy.
>
> New classes within 7.2 (e.g. \HashContext) to
On Mon, Feb 6, 2017 at 6:21 PM, Fleshgrinder wrote:
> Hey guys! :)
>
> First: I like namespaces in Core but here me out!
>
> https://wiki.php.net/rfc/libsodium
>
> The second vote is clearly going to be that this new feature is added to
> the core with a namespace. I already complained about this
> On Feb 6, 2017, at 13:50, Peter Cowburn wrote:
>
> a vote which essentially is about adopting
> namespaces in core, via new library RFC, is not the way to go about
> changing our coding standards. In short, I don't want to the see the
> situation where this extension gets merged in to 7.2 (wh
On Mon, Feb 6, 2017 at 12:21 PM, Fleshgrinder wrote:
> First: I like namespaces in Core but here me out!
>
> The PHP (case does not matter) would be the proper vendor name to put
> Core stuff in, as far as I remember it is also reserved for PHP
> functionality. There were also numerous discussions
On 6 February 2017 at 17:21, Fleshgrinder wrote:
> Hey guys! :)
>
> First: I like namespaces in Core but here me out!
>
> https://wiki.php.net/rfc/libsodium
>
> The second vote is clearly going to be that this new feature is added to
> the core with a namespace. I already complained about this bu
Hi all,
Having seen no further discussion I'd like to open the RFC[1] for voting.
Voting will be given just over 2 weeks ending Feb 22nd. RFC has
implementation[2] and language spec change[3] for review.
Thanks!
--
Dave
[1] - https://wiki.php.net/rfc/list_reference_assignment
[2] - https://git
Hey guys! :)
First: I like namespaces in Core but here me out!
https://wiki.php.net/rfc/libsodium
The second vote is clearly going to be that this new feature is added to
the core with a namespace. I already complained about this but it seems
to go unnoticed or others do not see the potential pr
On 2/6/2017 1:33 PM, Anatol Belski wrote:
> With the names and API, probably some more clarity should be. AFM,
> the low level units should be exposed, rather than a concrete time.
> Also, the name hrtime() is probably not much speaking. Maybe these
> three?
>
> sys_get_monotonic_ticks()
> sys_get
Hi,
> -Original Message-
> From: Anatol Belski [mailto:anatol@belski.net]
> Sent: Monday, October 31, 2016 6:02 PM
> To: 'PHP internals list' ; 'internals-win'
w...@lists.php.net>; php-wind...@lists.php.net
> Subject: [PHP-WIN] New PHP SDK for Windows
>
> Hi,
>
> I'm working on the
Hi Niklas,
> -Original Message-
> From: Niklas Keller [mailto:m...@kelunik.com]
> Sent: Sunday, February 5, 2017 8:19 PM
> To: Anatol Belski
> Cc: Leigh ; Michael Wallner ; PHP Internals
> ; Bob Weinand ; Daniel Lowrey
>
> Subject: Re: [PHP-DEV] Fwd: Monotonic Time
>
> I have implemente
On 05/02/17 23:25, Alex Bowers wrote:
> And here is the previous messaging without borked formatting. Sorry folks.
>
>
> FFI RFC
> ==
>
> There are many languages that support an FFI implementation.
>
> NodeJS
> Python
> C++
> Ruby
>
> FFI allows you to call a native C function without req
18 matches
Mail list logo
