On Tue, Jul 21, 2020, at 3:31 AM, Rowan Tommins wrote:
> On Tue, 21 Jul 2020 at 01:36, Mark Randall wrote:
>
> > So either you fake namespaces e.g. PhpToken or you trample on userland
> > \Tokenizer.
> >
>
>
> While you're making a reasonable point, I really wish people would stop
> using that
On Tue, 21 Jul 2020 at 01:36, Mark Randall wrote:
> So either you fake namespaces e.g. PhpToken or you trample on userland
> \Tokenizer.
>
While you're making a reasonable point, I really wish people would stop
using that particular class as an example, because I don't think the "PHP"
in its na
On 20/07/2020 16:58, Michael Wallner wrote:
Distilled down, I just cannot see any huge benefit out of a (or two) root
namespace(s). As a project we rightfully own the root namespace, and
putting everything beneath PHP just doesn't make any sense to me.
You cannot just "own" the root namespace i
On Mon, 20 Jul 2020 at 16:58, Michael Wallner wrote:
> Distilled down, I just cannot see any huge benefit out of a (or two) root
> namespace(s). As a project we rightfully own the root namespace, and
> putting everything beneath PHP just doesn't make any sense to me.
>
I will ask you the same q
Hi Larry!
Larry Garfield schrieb am Mi., 24. Juni 2020,
02:30:
> Greetings, Internalians.
>
> *dons flame retardant suit*
Thank your for your efforts, but I'm about to cast a negative vote on this
policy.
Distilled down, I just cannot see any huge benefit out of a (or two) root
namespace(s).
On Fri, Jul 17, 2020, at 7:20 AM, Mark Randall wrote:
> On 17/07/2020 09:23, Lester Caine wrote:
> > So does that also apply to \Ext? Currently the selection of extensions
> > is flexible and most distributions allow the easy repackaging of just
> > what is available. Creating a 'core' set off ex
On 17/07/2020 09:23, Lester Caine wrote:
So does that also apply to \Ext? Currently the selection of extensions
is flexible and most distributions allow the easy repackaging of just
what is available. Creating a 'core' set off extensions under \PHP is
essentially saying 'you will make these ava
On Fri, 17 Jul 2020 at 04:50, Levi Morrison via internals <
internals@lists.php.net> wrote:
> This is not quite the same. I said it moves from _userland_ aka PHP
> code, to an _extension_ aka C code. I oppose `Ext` in both case.
>
Hi Levi,
Given this, I presume you also oppose `PHP\` for those
On 16/07/2020 22:42, Larry Garfield wrote:
After some discussion, the namespacing proposal has been again updated. Two
major changes:
1) Only engine code goes in \PHP. There's a separate \Ext namespace for
extensions, whether bundled or PECL.
From RFC ...
" This RFC does NOT propose moving
On 17/07/2020 04:49, Levi Morrison via internals wrote:
I don't care to debate it. I will just vote no.
Fair enough, however the point of the internals mailing list and
discussion period is to debate the RFCs :-)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
On Thu, Jul 16, 2020 at 9:29 PM Mark Randall wrote:
>
> On 17/07/2020 02:58, Levi Morrison via internals wrote:
> >2. I don't think this is solving any problems, really:
> > - Code can move from PHP land to an extension and back again.
> > Should the namespace change just because it moved
On 17/07/2020 02:58, Levi Morrison via internals wrote:
2. I don't think this is solving any problems, really:
- Code can move from PHP land to an extension and back again.
Should the namespace change just because it moved one way or the
other? I vote no.
This is not what the RFC propos
On Thu, Jul 16, 2020 at 3:42 PM Larry Garfield wrote:
>
> After some discussion, the namespacing proposal has been again updated. Two
> major changes:
>
> 1) Only engine code goes in \PHP. There's a separate \Ext namespace for
> extensions, whether bundled or PECL.
>
> 2) It establishes that a
After some discussion, the namespacing proposal has been again updated. Two
major changes:
1) Only engine code goes in \PHP. There's a separate \Ext namespace for
extensions, whether bundled or PECL.
2) It establishes that an index will be maintained on the Wiki listing what
namespaces are a
On 10/07/2020 09:54, Nikita Popov wrote:
For me, dealing with PHP <-> PECL moves is an important part of adopting
namespaces in php-src, and I don't think the current proposal addresses
this issue sufficiently. (One way to address it would be to drop the PHP\
prefix, and use unvendored namespace
On Thu, 9 Jul 2020 at 18:04, Larry Garfield wrote:
>
> I've no idea what the rules are around new version numbers
> of RFCs that haven't been up for a vote yet.
I pretty strongly recommend people against re-using documents. If it's
going to change significantly, using a new doc makes it easier to
On Fri, Jul 10, 2020, at 3:54 AM, Nikita Popov wrote:
> On Tue, Jul 7, 2020 at 4:47 PM Larry Garfield
> wrote:
>
> > On Tue, Jun 23, 2020, at 7:30 PM, Larry Garfield wrote:
> > > Greetings, Internalians.
> > >
> > > There has been much talk of the \PHP namespace of late, including one
> > > unsuc
On Tue, Jul 7, 2020 at 4:47 PM Larry Garfield
wrote:
> On Tue, Jun 23, 2020, at 7:30 PM, Larry Garfield wrote:
> > Greetings, Internalians.
> >
> > There has been much talk of the \PHP namespace of late, including one
> > unsuccessful RFC. In the discussion, the pushback broke down into two
> >
On Thu, 9 Jul 2020 at 18:14, Derick Rethans wrote:
> On Thu, 9 Jul 2020, Rowan Tommins wrote:
>
> > And yet we have repeatedly had discussions about whether this or that
> > feature should or shouldn't be prefixed with a namespace. If you think
> > the correct answer to "when should we use the PH
On Thu, 9 Jul 2020, Rowan Tommins wrote:
> And yet we have repeatedly had discussions about whether this or that
> feature should or shouldn't be prefixed with a namespace. If you think
> the correct answer to "when should we use the PHP\ prefix?" is
> "never", I urge you to put forward an RFC
On Thu, Jul 9, 2020, at 6:55 AM, Rowan Tommins wrote:
> On Thu, 9 Jul 2020 at 09:58, Dan Ackroyd wrote:
>
> > On Tue, 7 Jul 2020 at 15:47, Larry Garfield
> > wrote:
> > >
> > > This has reached the 2 week mark, but there's not been much discussion.
> >
> > Unless I'm having a massive reading fai
On Thu, 9 Jul 2020 at 09:58, Dan Ackroyd wrote:
> On Tue, 7 Jul 2020 at 15:47, Larry Garfield
> wrote:
> >
> > This has reached the 2 week mark, but there's not been much discussion.
>
> Unless I'm having a massive reading failure, this RFC has been
> announced twice. And feedback was provided b
On Tue, 7 Jul 2020 at 15:47, Larry Garfield wrote:
>
> This has reached the 2 week mark, but there's not been much discussion.
Unless I'm having a massive reading failure, this RFC has been
announced twice. And feedback was provided before:
https://externals.io/message/109646#109647
https://exte
On Tue, Jul 7, 2020, at 5:31 PM, David Rodrigues wrote:
> There are some problem by using double back slash for PHP namespace?
>
> Eg. Instead of \PHP\String be just \\String.
Currently that's a syntax error, and I don't think we have time to change it
before the code freeze even if we could all
> On 8 Jul 2020, at 13:16, Michał Marcin Brzuchalski
> wrote:
>
> Hi Stephen,
>
> śr., 8 lip 2020 o 07:09 Stephen Reay napisał(a):
>
>> ...
>> IMO (and I know it’s not universal) acronyms should remain upper case.
>> Camel case is about upper casing the first letter of each word. The lette
Hi Stephen,
śr., 8 lip 2020 o 07:09 Stephen Reay napisał(a):
> ...
> IMO (and I know it’s not universal) acronyms should remain upper case.
> Camel case is about upper casing the first letter of each word. The letters
> of an acronym are all the first letters of words, thus DOM not Dom, etc.
>
> On 8 Jul 2020, at 05:11, Larry Garfield wrote:
>
> On Tue, Jul 7, 2020, at 4:22 PM, Miguel Rosales wrote:
>> Larry Garfield wrote on 07/07/2020 16:46:
>>> This has reached the 2 week mark, but there's not been much discussion.
>>> Anyone else want to weigh in?
>>>
>>
>> I guess I'm missi
There are some problem by using double back slash for PHP namespace?
Eg. Instead of \PHP\String be just \\String.
Em ter, 7 de jul de 2020 19:04, Larry Garfield
escreveu:
> On Tue, Jul 7, 2020, at 4:22 PM, Miguel Rosales wrote:
> > Larry Garfield wrote on 07/07/2020 16:46:
> > > This has reache
On Tue, Jul 7, 2020, at 4:22 PM, Miguel Rosales wrote:
> Larry Garfield wrote on 07/07/2020 16:46:
> > This has reached the 2 week mark, but there's not been much discussion.
> > Anyone else want to weigh in?
> >
>
> I guess I'm missing something obvious here, but the RFC says:
>
> > 5. Compon
On Tue, 7 Jul 2020 at 15:47, Larry Garfield wrote:
> This has reached the 2 week mark, but there's not been much discussion.
> Anyone else want to weigh in?
>
Looks good; nothing more to say. 👍
Peter
On 07/07/2020 15:46, Larry Garfield wrote:
This has reached the 2 week mark, but there's not been much discussion. Anyone
else want to weigh in?
We wanted to add that, general sentiment seems to be moving towards
using Exceptions for communicating errors, potentially including a large
effor
On Tue, Jun 23, 2020, at 7:30 PM, Larry Garfield wrote:
> Greetings, Internalians.
>
> There has been much talk of the \PHP namespace of late, including one
> unsuccessful RFC. In the discussion, the pushback broke down into two
> main camps:
>
> * We should never namespace anything ever.
> *
> On Jun 23, 2020, at 8:30 PM, Larry Garfield wrote:
>
> Greetings, Internalians.
>
> There has been much talk of the \PHP namespace of late, including one
> unsuccessful RFC. In the discussion, the pushback broke down into two main
> camps:
>
> * We should never namespace anything ever.
>
On Wed, Jun 24, 2020, at 2:32 PM, Rowan Tommins wrote:
> On 24/06/2020 01:30, Larry Garfield wrote:
> > * We should never namespace anything ever.
> > * We can namespace things but we need something more concrete than "RFCs
> > can namespace things if they feel like it."
> >
> > I can't do much ab
On 24/06/2020 01:30, Larry Garfield wrote:
* We should never namespace anything ever.
* We can namespace things but we need something more concrete than "RFCs can
namespace things if they feel like it."
I can't do much about the former, but the latter is a solvable problem. To
that end, Mark
35 matches
Mail list logo
