On Tue, Feb 7, 2017 at 6:59 PM, Dan Ackroyd wrote:
> On 7 February 2017 at 17:56, Scott Arciszewski wrote:
>> I'm taking all the No votes spawned by this thread to mean "we
>> don't want namespaced functions ever".
>
> That would be a bad assumption.
>
Confirmed. I'm not against EVER having names
On 7 February 2017 at 17:56, Scott Arciszewski wrote:
> I'm taking all the No votes spawned by this thread to mean "we
> don't want namespaced functions ever".
That would be a bad assumption.
Peter Cowburn wrote:
> Slinking in a vote which essentially is about adopting
> namespaces in core, via
On Mon, Feb 6, 2017 at 12: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 thi
On 2/7/2017 11:39 AM, Niklas Keller wrote:
> I don't see this as a potential problem. Autoloadeds are (1) not triggered
> for already loaded symbols and (2) and more importantly, autoloaders
> usually use a list of prefixes to load, so a whitelist, not a blacklist.
>
> Regards, Niklas
>
This is
There will be breaking changes for the sodium users anyways since some
functions will not be included and the complete error handling needs to
be changed from errors to exceptions.
--
Richard "Fleshgrinder" Fussenegger
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visi
On Tue, Feb 7, 2017 at 12:00 PM, Derick Rethans wrote:
> On Mon, 6 Feb 2017, Nikita Popov wrote:
>
> > On Mon, Feb 6, 2017 at 6:21 PM, Fleshgrinder
> wrote:
> >
> > > First: I like namespaces in Core but here me out!
>
>
>
> > I'm strongly against use of the PHP namespace as a blanket namespace
On Mon, 6 Feb 2017, Stanislav Malyshev 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
On Mon, 6 Feb 2017, Sara Golemon wrote:
> 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 relat
On Mon, 6 Feb 2017, Nikita Popov wrote:
> On Mon, Feb 6, 2017 at 6:21 PM, Fleshgrinder wrote:
>
> > First: I like namespaces in Core but here me out!
> 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
>
> I thought about this too. I hope you understood that the main reasoning
> for me to choose a well known namespace prefix is related to
> auto-loading and when to trigger it. The lack of function and constant
> auto-loading is a pain and having well known prefixes could solve the
> issue since w
"Stanislav Malyshev" wrote in message
news:a8d24d41-bd3a-0881-3fcb-9366fe974...@gmail.com...
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. \ph
"Fleshgrinder" wrote in message
news:04295b76-3e0d-5ea3-7b4e-d07a15db4...@fleshgrinder.com...
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
On 07/02/17 08:53, Rowan Collins wrote:
>> I think the Sodium RFC vote is not about namespace but rather about
>> breaking everything which already use the pecl extension.
> Well, it's about both, that's why it's a hard question: in order not to break
> existing use of the extension, we need to br
Just my two cents, but moving and aliasing core PHP
classes/interfaces/functions sounds like an absolutely horrible idea.
My biggest question is WHY would you do that?
Writing user-space code today that uses the global namespace would be
considered extremely bad practice - no one should do that.
On 7 February 2017 06:52:32 GMT+00:00, Remi Collet
wrote:
>> 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.
Well, it's about both, that's why it's a hard question: in order not t
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
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
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
27 matches
Mail list logo
