Re: [PHP-DEV] Deprecate and remove case-insensitive constants?

This is only part of a thread. view whole thread
  100545
September 12, 2017 16:45 levim@php.net (Levi Morrison)
> Apologies if I've completely missed the point here.
Oh well, it happens.
> Are you saying that without case sensitivity, the language could deduce that sum2 in that case was a function reference? That seems optimistic: not only can you have a class, a constant, and a function all with the same name, but you can't actually know which exists until the line is executed, because all three can be defined at any time.
Close. If we make case sensitivity consistent (either all insensitive or all sensitive) *and* merge symbol tables then we can get actual features out of it. As it stands just changing the case sensitivity does not buy as any features for our BC break. The rest of my message only makes sense once you understand I was proposing unified case sensitivity for all symbols *and* merging them into one table.
>> array_map(sum2, $input1, $input2); >> >>Currently that requires `sum2` to be a constant. > > I'm not clear what this has to do with case sensitivity; the problem here is that we don't have a type of "function reference" (nor "class reference") so simulate such references with strings and runtime assertions.
This confusion stems from the aforementioned items.
> If we want function and class references, they should have their own, unambiguous, syntax.
My point was rather that if we fix our inconsistency issues and merge the tables no such syntax is required; all existing syntax works. There are engine changes that have to accompany those as well, obviously. In summary I think changing constant case sensitivity is too small of a step to gain us anything, but would be *very* happy to take it further because it will give us actual features for our trouble.
  100548
September 12, 2017 17:59 rowan.collins@gmail.com (Rowan Collins)
On 12 September 2017 17:45:46 BST, Levi Morrison <levim@php.net> wrote:
>The rest of my message only makes sense once you understand I was >proposing unified case sensitivity for all symbols *and* merging them >into one table.
Ah, OK, so I partially missed the point. I'm still not sure what you're suggesting is sensible, though...
>> If we want function and class references, they should have their own, >>unambiguous, syntax.
I stand by this assertion. Consider the following statement: $foo = bar; Even if "bar" cannot *simultaneously* be the name of a function, a class, and a constant, it can still *potentially* be any of the three, from the point of view of the compiler. So, far from allowing us to make nice inferences about function references vs strings-that-look-callable, we have now *broken* assumptions we could previously have made. It seems like we'd just be adding another equally ambiguous way of writing the same code. Regards, -- Rowan Collins [IMSoP]
  100551
September 12, 2017 20:35 levim@php.net (Levi Morrison)
On Tue, Sep 12, 2017 at 11:59 AM, Rowan Collins collins@gmail.com> wrote:
> On 12 September 2017 17:45:46 BST, Levi Morrison <levim@php.net> wrote: >>The rest of my message only makes sense once you understand I was >>proposing unified case sensitivity for all symbols *and* merging them >>into one table. > > Ah, OK, so I partially missed the point. I'm still not sure what you're suggesting is sensible, though... > > >>> If we want function and class references, they should have their own, >>>unambiguous, syntax. > > I stand by this assertion. Consider the following statement: > > $foo = bar; > > Even if "bar" cannot *simultaneously* be the name of a function, a class, and a constant, it can still *potentially* be any of the three, from the point of view of the compiler.
If it's known, it's known, and it can proceed with that type. If it's not known then autoload and proceed like normal. I fail to see how this is an issue, and in fact, see it as a *significant* improvement to our current situation...
  100559
September 13, 2017 13:48 rowan.collins@gmail.com (Rowan Collins)
Regards,
On 12 September 2017 21:35:51 BST, Levi Morrison <levim@php.net> wrote:
>On Tue, Sep 12, 2017 at 11:59 AM, Rowan Collins >collins@gmail.com> wrote: >>>> If we want function and class references, they should have their >own, >>>>unambiguous, syntax. >> >> I stand by this assertion. Consider the following statement: >> >> $foo = bar; >> >> Even if "bar" cannot *simultaneously* be the name of a function, a >class, and a constant, it can still *potentially* be any of the three, >from the point of view of the compiler. > >If it's known, it's known, and it can proceed with that type. If it's >not known then autoload and proceed like normal. I fail to see how >this is an issue, and in fact, see it as a *significant* improvement >to our current situation...
If the symbol tables had always been unified, I guess you could think of a function name as a constant whose value happened to be of type IS_FUNC - like how in JS "function foo() {}" and "var foo = function{}" are very nearly interchangeable. But it feels like retrofitting that onto the existing language would be messy. For instance, an autoloader would have to be given a token name, with no context of whether it's expected to be a class, function, or constant. (Of course we'd have to solve the dilemma of how global function fallback/shadowing should interact with autoloading first.) Users would have to learn this concept of an untyped token, because the error message they'd get if it wasn't defined could no longer say "undefined constant". Then there's all the existing support for string-based callables. I can't actually think of any cases that are unresolvable, but there's some odd implications: function foo() { echo 'Hello, world!'; } const bar='foo'; $fn = bar; $fn(); // already works bar(); // would this work? if not, why not, since it's no longer ambiguous? const baz='bar'; $fn2 = baz; $fn2(); // in which case, would this also work? baz(); // and then what about this? I feel like this could lead to confusion either way, and just increase the complexity for both human and machine analysis. Then there's other symbol tables that would need to be unified - we'd want $foo->bar be able to grant a method reference, and Foo::bar a static method reference. Just how much code is it worth breaking to allow this syntax? It feels a lot cleaner to say "function and class references are a new concept, and you'll know when you're using them because they look like this". Something like "SomeClass::classref", "some_func::funcref", "SomeClass::someStaticMethod::funcref", "$some_object->someMethod::funcref".   -- Rowan Collins [IMSoP]