Re: Deprecate and remove case-insensitive constants?

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 ><rowan.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]