> On Jan 6, 2020, at 5:52 PM, Rowan Tommins wrote:
>
> On 06/01/2020 21:01, Mike Schinkel wrote:
>>> On Jan 6, 2020, at 5:56 AM, Robert Hickman wrote:
>>>
>>> Would it be worth expanding the ideas of programmatic constant
>>> definition into a more general compile-time code execution approach?
> On Jan 6, 2020, at 4:59 PM, Rowan Tommins wrote:
> I'm still struggling to understand why you need multiple constants, all
> mutable based on some other dimension.
> If the ultimate goal is to know the name and branch of the *current*
> environment, how do the constants help?
At least two co
> On Jan 6, 2020, at 4:24 PM, Larry Garfield wrote:
> For example:
>
> const DEBUG_MODE = false;
>
> function foo() {
> if (DEBUG_MODE) {
>// Do stuff.
> }
> }
>
> PHP will currently (AIUI) inline the DEBUG_MODE value at compile time, notice
> that the code path is unreachable, and omi
> const DEBUG_MODE = false;
>
> function foo() {
> if (DEBUG_MODE) {
>// Do stuff.
> }
> }
>
> PHP will currently (AIUI) inline the DEBUG_MODE value at compile time,
> notice that the code path is unreachable, and omit it from the compiled
> opcodes entirely.
> (I'm pretty sure it does th
On 06/01/2020 21:01, Mike Schinkel wrote:
On Jan 6, 2020, at 5:56 AM, Robert Hickman wrote:
Would it be worth expanding the ideas of programmatic constant
definition into a more general compile-time code execution approach?
That would certainly be interesting. I do not know enough what is pos
On 05/01/2020 21:53, Mike Schinkel wrote:
Yet you called my list of URLs enums, and they are not at all arbitrary and
absolutely want to change.
I apologise - I took a guess without context for how those constants
would be used, but apparently they're something rather different.
I take i
On Mon, Jan 6, 2020, at 2:28 PM, Mike Schinkel wrote:
> > On Jan 6, 2020, at 1:07 PM, Larry Garfield wrote:
*snip*
> From: https://en.wikipedia.org/wiki/Status_quo_bias
>
> But if I mischaracterized your objections I apologize.
I am not anti-change for anti-change's sake. Since I presume fr
> On Jan 6, 2020, at 5:56 AM, Robert Hickman wrote:
>
> Would it be worth expanding the ideas of programmatic constant
> definition into a more general compile-time code execution approach?
> It would work well with preloading introduced in 7.4, and could allow
> some of the things frameworks are
> On Jan 6, 2020, at 1:07 PM, Larry Garfield wrote:
>
> Do not put words in my mouth and presume to know what I would think in some
> hypothetical situation. That is rude and inappropriate.
I do not mean to nor want to start any conflict here. I know I felt some of
your phrasing rude and so I
> On Jan 5, 2020, at 5:04 PM, tyson andre wrote:
>
> I have a work in progress wrapper for allowing const-like syntax for global
> constants `static const X = $dynamicExpression;`.
> This can be seen in https://github.com/TysonAndre/php-src/pull/10
Thanks for replying and including this. Nice
On Mon, Jan 6, 2020 at 7:18 PM Larry Garfield
wrote:
> On Mon, Jan 6, 2020, at 5:16 AM, Nikita Popov wrote:
>
> > Others have already explained why constructors are exempted from LSP
> > checks, so let me reply to your other point...
> >
> > I believe that your example should indeed be legal in g
On Mon, Jan 6, 2020, at 5:16 AM, Nikita Popov wrote:
> Others have already explained why constructors are exempted from LSP
> checks, so let me reply to your other point...
>
> I believe that your example should indeed be legal in general and created a
> PR to fix this: https://github.com/php/php
Lots to reply to here, so I'm going to munge it into a single response.
Mike Schinkel said:
> Let's consider the fact that is PHP had never had the define() and instead
> implemented the `const` keyword from the start, and only allowed compile time
> values. If PHP had done that, you would be
On Mon, 6 Jan 2020 at 10:29, Gabriel Caruso
wrote:
> Hello George
>
> On Mon, 6 Jan 2020 at 01:28, G. P. B. wrote:
>
>> On Sun, 5 Jan 2020 at 18:44, Gabriel Caruso
>> wrote:
>>
>>> Hello Internals,
>>>
>>> I have a PR proposing to start checking the signatures for PHP magic
>>> methods in the n
On Sun, Dec 8, 2019 at 1:29 AM Larry Garfield
wrote:
> I am not sure if this is a bug, a feature behaving in a desired but
> confusing way, or a feature behaving in a confusing and thus undesireable
> way. I am therefore reporting it here in order to defer to those who know
> the answer to such
Would it be worth expanding the ideas of programmatic constant
definition into a more general compile-time code execution approach?
It would work well with preloading introduced in 7.4, and could allow
some of the things frameworks are currently doing at runtime to be
done once at compile time (opc
Hello George
On Mon, 6 Jan 2020 at 01:28, G. P. B. wrote:
> On Sun, 5 Jan 2020 at 18:44, Gabriel Caruso
> wrote:
>
>> Hello Internals,
>>
>> I have a PR proposing to start checking the signatures for PHP magic
>> methods in the next major version of PHP:
>> https://github.com/php/php-src/pull/4
On Mon, 6 Jan 2020 at 10:05, Nikita Popov wrote:
> On Sun, Jan 5, 2020 at 6:44 PM Gabriel Caruso
> wrote:
>
>> Hello Internals,
>>
>> I have a PR proposing to start checking the signatures for PHP magic
>> methods in the next major version of PHP:
>> https://github.com/php/php-src/pull/4177. The
On Sun, Jan 5, 2020 at 7:48 PM Rowan Tommins
wrote:
> On 05/01/2020 18:03, tyson andre wrote:
> >> Yes, I'm saying that the autoloader should be called for each lookup, so
> >> autoloading of Foo\strlen should come between checking if Foo\strlen is
> >> defined, and checking if \strlen is defined
On Sun, Jan 5, 2020 at 6:44 PM Gabriel Caruso
wrote:
> Hello Internals,
>
> I have a PR proposing to start checking the signatures for PHP magic
> methods in the next major version of PHP:
> https://github.com/php/php-src/pull/4177. The idea for this PR came from
> https://bugs.php.net/bug.php?id
20 matches
Mail list logo
