Hi all,
While I was reading through the discussion, I found a question related
to the conflict of constant names and functions names. In other words,
`strlen` can be both a constant name and a function name. Thus, in
pipe RFC, it can go confusing whether it is a constant or a function
name when called this way:
```
'abc'
|> strtoupper
|> md5(?, true)
|> bin2hex
|> base64_encode;
```
In Javascript alert and confirm are by default names. In reality, they
are methods of window object. When they are assigned to a new value,
they don't give a reference to the methods of window object.
When a function or a method name is referred without parenthesis,
JavaScript returns the function object. It is Useful because it does
not require quoting. For example, `window.setTimeout(alert, 1000);`.
A more popular example is `if (window.XMLHttpRequest)`.
Even I tested this, and it worked. I hated this behavior.
```
function ok(){};
console.log(typeof ok);
ok = 123;
console.log(typeof ok);
```
In PHP, all in-namespace symbols are first searched in the namespace.
If not found, they are looked in the global namespace. If still not
found, the error is thrown.
In the light of these two examples, I have these suggestions:
1. declare all function/method names respectively constants and
variables by default and make them modifiable. This functionality is
present in OOP; it is possible to redeclare constants and methods that
are non-final.
2. As you have removed the ability to declare a case-insensitive
constant, stop invocation of function names case-insensitively. Of
course, it requires an RFC.
3. Disallow declaration of constants and using the names of functions
static methods. Same applies to variables and non static methods of a
class. As a result, no one can declare `strlen` as a constant. If one
tries to make a method with a name of a property, it will also get an
error.
I don't know how many bc breaks these applications will bring. If they
are approved, I am sure it will not only solve the problem that gave
birth to this idea, but also it will prevent bad practices. For
example,
```
<?php
class mc
{
public $mc;
public const mc = '';
public static function mc(){}
/* line 7 */ public function mc(){}
};
```.
When I ran this, I got following:
`PHP Fatal error: Cannot redeclare mc::mc() in test.php on line 7`
Static methods are called using a static scope operator `::` but
non-static are not, still one cannot declare these sort of methods
with a sane bane. Why not stop people from using a single name
everywhere and following this bad coding practice?
Larry, you need to resolve these issues before you can pass function
names as callables without quoting them.
Best
Hamza Ahmad
On 7/1/21, Olle Härstedt <olleharst...@gmail.com> wrote:
> 2021-06-30 19:10 GMT+02:00, Larry Garfield <la...@garfieldtech.com>:
>> On Wed, Jun 30, 2021, at 8:59 AM, Olle Härstedt wrote:
>>
>>> > I've been pondering if a completely different approach with a prefix
>>> > symbol would be able to be less complex, and the simple answer is I
>>> > have absolutely no idea. But we are running low on symbols...
>>>
>>> Ah, I found the technical details that Joe gave me (right after I hit
>>> send, of course). Quoting Joe:
>>>
>>> "the engine expects certain things to happen, and is designed and then
>>> optimized around those assumptions ... for example, a stream of INIT,
>>> SEND, DO_FCALL is not meant to be interrupted, the first fundamental
>>> change you have to make is making the engine aware that stream of INIT,
>>> SEND, + are not always followed by DO_FCALL "
>>>
>>> So yes, it sounds like hooking into the function call process is where
>>> the complexity comes from. Which suggests that an approach that works
>>> using a different syntax that desugars to a closure would avoid that
>>> issue, but then we need a syntax that wouldn't be ambiguous, and that's
>>> getting harder and harder to find. (Nikita's first-class-callables RFC
>>> notes some of the issues with available symbols, and they're
>>> essentially the same for partials either way.) And I've been told that
>>> creating closures in the AST compiler is Hard(tm)...
>>>
>>> --Larry Garfield
>>>
>>>
>>> Wrapping stuff in lambdas is otherwise the obvious solution, no? Make
>>> `strlen(?)` evaluate to `fn ($x) => strlen($x)`. Does it depend on the
>>> level of look-ahead in the compiler why it's so hard? Didn't work much
>>> with scripting language internals.
>>>
>>> Olle
>>
>> The tricky part is that conversion has to happen entirely at runtime,
>> because we need the type information from the function being partialed,
>> and
>> at that point creating an actual closure is, apparently, rather hard. It
>> cannot be done up at the AST level where it would be conceptually much
>> easier.
>>
>> We've been discussing this for the past several days in chat, and the
>> basic
>> conclusion is that the PHP engine does not offer any easy way to do this.
>> It's one hard-and-messy approach or another hard-and-messy approach. So
>> far
>> no one has figured out a not hard-and-messy way to make it work,
>> regardless
>> of performance.
>>
>> --Larry Garfield
>
> Alright, alright. Guess I have to learn a bit more about the different
> passes inside the compiler. :) Thanks.
>
> Olle
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
