[Vote] Partial Function Application

Le Thu, 17 Jun 2021 08:37:23 -0500,
"Larry Garfield" larry@garfieldtech.com a écrit :

$c = stuff(...);
$c = fn(int $i, string $s, float $f, Point $p, int $m = 0)
=> stuff($i, $s, $f, $p, $m);

$c = stuff(1, 'hi', 3.4, $point, 5, ...);
$c = fn(...$args) => stuff(1, 'hi', 3.4, $point, 5, ...$args);

Why is there an additional variadic parameter in this one?

... means "zero or more". In this case, it means zero, that is, it creates a
closure that requires no arguments and will call the original function with
all of the provided values later. This is the "deferred function" use case
mentioned further down.

I still do not understand why there is an added variadic parameter when
using ... in stuff(1, 'hi', 3.4, $point, 5, ...); but not when using it in
stuff(...);
What happens when we use stuff(1, 'hi', 3.4, $point, ...); ?

Also, in the second set of examples:

function things(int $i, float $f, Point ...$points) { ... }

// Ex 13
$c = things(...);
$c = fn(int $i, float $f, ...$args) => things(...[$i, $f, ...$args]);

// Ex 14
$c = things(1, 3.14, ...);
$c = fn(...$args) => things(...[1, 3.14, ...$args]);

What happens to the typing of the variadic parameter here? Why is it
removed?

It would feel natural that the ... means "copy the rest of the parameters
from signature". Here it seems it sometimes mean that, and sometimes mean
"accept an additional variadic parameter and pass it along".

Internally placeholders do mean the former. A trailing variadic, though, can
accept extra arguments of potentially not pre-defined types, so it sort of
straddles the line. Variadics make things weird. :-) (Dating from PHP
5.6.) In the majority case, though, thinking of them as "copy the rest of
the arguments" is accurate.

I do not understand why Points ...$points becomes untyped ...$args when using
things(...), while when using stuff(...) earlier no typing was lost.

Côme

Le Thu, 17 Jun 2021 08:30:43 -0500,
"Larry Garfield" larry@garfieldtech.com a écrit :

The ? character was chosen for the placeholder largely because it was
unambiguous and easy to implement. Prior, similar RFCs (such as the
original Pipe Operator proposal from several years ago) used the $$
(lovingly called T_BLING) sigil instead. So far no compelling argument
has been provided for changing the character, so the RFC is sticking
with ?.

The main argument for $$ is to be able to have partial methods with $$->,
this should be stated in this paragraph.

That's not something that was ever brought up in the discussion.

Finally found where I read that, it’s in an other RFC:
https://wiki.php.net/rfc/first_class_callable_syntax#partial_function_application

Côme

I'd like to note a couple of things ...

The behaviour of nullsafe and strict types being unspecified in the RFC
would allow us to solve those problems later.

The behaviour of strict types right now is objectively wrong, the partial
takes strictness from the application site, so as Nikita already knew when
he asked the question; calls from a non-strict file will not behave as you
expect.

With regard to the complexity in the implementation: I think it's important
to understand that the complexity of the implementation is a product of the
semantics we landed on during discussion.

The first implementation where we only had ? was technically simpler, but
not intuitive from a user perspective.

Now we have semantics that are easy to understand, that you can communicate
in a few lines. But the implementation is necessarily complicated as a
result of those semantics.

We also have to remember that this is actually some kind of middle ground,
it's not the most complicated version of partial application we could have

• because that most complicated version would also include support for
  re-ordering parameters (named placeholders), and nor is it the simplest
  which offloaded a lot of (cognitive) overhead onto the programmer.

The question is not can we simplify the implementation, the question is
rather, is the necessary complexity of an implementation with the kind of
semantics that are desirable justified.

Cheers
Joe

On Mon, 21 Jun 2021 at 16:26, Björn Larsson via internals <
internals@lists.php.net> wrote:

Den 2021-06-18 kl. 16:08, skrev Nikita Popov:

On Wed, Jun 16, 2021 at 6:17 PM Larry Garfield larry@garfieldtech.com
wrote:

Hi folks. The vote for the Partial Function Application RFC is now
open,
and will run until 30 June.

https://wiki.php.net/rfc/partial_function_application

Of particular note, a few people had asked about using ...? instead of
...
for the variadic placeholder. In the end we decided not to explore
that,
as Nikita explained off-list it was actually more confusing, not less,
as
it would suggest "placeholder for a variadic" rather than "a placeholder
that is variadic." Otherwise, it's just more typing. The syntax
choices
section of the RFC has been updated accordingly.

A couple of notes on the content (or non-content) of the RFC:

• The behavior of nullsafe calls with PFA has been brought up in the
  discussion, but is not mentioned in the RFC. For reference, $foo?->bar(?)
  is the same as $foo !== null ? $foo->bar(?) : null. I don't think the
  behavior is particularly unreasonable, but I also think it's not
  particularly useful and may be surprising (in that there is a plausible
  alternative behavior). I think you may have been better off forbidding
  that
  case.

• The behavior of parameter names / reflection with regard to variadic
  parameters is very odd. For function test(...$args) and test(?, ?, ?) you
  get back a function that nominally has three parameters with the name
  $args. Parameter names in PHP are generally required to be unique, and of
  course this also has implications for named arguments, for example this
  works, while it probably shouldn't:
  https://3v4l.org/cQITD/rfc#focus=rfc.partials To be honest, I'm not sure
  what the right way to handle this is, but I don't think this is it. A
  possibility would be to bring back the concept of name-less parameters we
  had prior to PHP 8 (for internal functions only), or possibly to make the
  signature less precise by simply retaining an ...$args parameter, and
  just
  making the enforcement of "at least three parameters" an implementation
  detail. The latter seems like the best option.

• The RFC doesn't specify how PFA interacts with strict types. If I
  create
  a partially-applied function in strict_types=1 file and call it in a
  strict_types=0 file, what happens? Will it use strict_types=0 semantics,
  including for arguments that were bound in the strict_types=1 file?

• It's worth noting that the "new Foo(?)" syntax will create and destroy
  a
  Foo object as part of creating the partial (not just a call to the
  partial). I've mostly convinced myself that this is probably harmless.
  It
  would have interacted negatively with an earlier version of
  https://wiki.php.net/rfc/new_in_initializers, but I think the problem
  there
  was not on the side of partials.

In any case, I'm voting no on this one: While PFA is simple on a
conceptual
level, the actual proposal is complex and has lots of tricky edge cases.
Especially once you take a look at the implementation. I'm not convinced
that PFA in its full generality is justified for inclusion in PHP.

Regards,
Nikita

Would you look on this feature in a different light if the above
concerns about strict types and nullsafe calls could be clarified /
solved? Or is it about the implementation with it's complexity and
tricky edge cases?

I myself think one should take into account that this is a feature
that would make PHP stand out even more. Not being a follower of
other languages here :-)

Regards //Björn L

--

To unsubscribe, visit: https://www.php.net/unsub.php

On Mon, Jun 21, 2021 at 4:26 PM Björn Larsson bjorn.x.larsson@telia.com
wrote:

Den 2021-06-18 kl. 16:08, skrev Nikita Popov:

On Wed, Jun 16, 2021 at 6:17 PM Larry Garfield larry@garfieldtech.com
wrote:

Hi folks. The vote for the Partial Function Application RFC is now
open,
and will run until 30 June.

https://wiki.php.net/rfc/partial_function_application

Of particular note, a few people had asked about using ...? instead of
...
for the variadic placeholder. In the end we decided not to explore
that,
as Nikita explained off-list it was actually more confusing, not less,
as
it would suggest "placeholder for a variadic" rather than "a placeholder
that is variadic." Otherwise, it's just more typing. The syntax
choices
section of the RFC has been updated accordingly.

A couple of notes on the content (or non-content) of the RFC:

• The behavior of nullsafe calls with PFA has been brought up in the
  discussion, but is not mentioned in the RFC. For reference, $foo?->bar(?)
  is the same as $foo !== null ? $foo->bar(?) : null. I don't think the
  behavior is particularly unreasonable, but I also think it's not
  particularly useful and may be surprising (in that there is a plausible
  alternative behavior). I think you may have been better off forbidding
  that
  case.

• The behavior of parameter names / reflection with regard to variadic
  parameters is very odd. For function test(...$args) and test(?, ?, ?) you
  get back a function that nominally has three parameters with the name
  $args. Parameter names in PHP are generally required to be unique, and of
  course this also has implications for named arguments, for example this
  works, while it probably shouldn't:
  https://3v4l.org/cQITD/rfc#focus=rfc.partials To be honest, I'm not sure
  what the right way to handle this is, but I don't think this is it. A
  possibility would be to bring back the concept of name-less parameters we
  had prior to PHP 8 (for internal functions only), or possibly to make the
  signature less precise by simply retaining an ...$args parameter, and
  just
  making the enforcement of "at least three parameters" an implementation
  detail. The latter seems like the best option.

• The RFC doesn't specify how PFA interacts with strict types. If I
  create
  a partially-applied function in strict_types=1 file and call it in a
  strict_types=0 file, what happens? Will it use strict_types=0 semantics,
  including for arguments that were bound in the strict_types=1 file?

• It's worth noting that the "new Foo(?)" syntax will create and destroy
  a
  Foo object as part of creating the partial (not just a call to the
  partial). I've mostly convinced myself that this is probably harmless.
  It
  would have interacted negatively with an earlier version of
  https://wiki.php.net/rfc/new_in_initializers, but I think the problem
  there
  was not on the side of partials.

In any case, I'm voting no on this one: While PFA is simple on a
conceptual
level, the actual proposal is complex and has lots of tricky edge cases.
Especially once you take a look at the implementation. I'm not convinced
that PFA in its full generality is justified for inclusion in PHP.

Regards,
Nikita

Would you look on this feature in a different light if the above
concerns about strict types and nullsafe calls could be clarified /
solved? Or is it about the implementation with it's complexity and
tricky edge cases?

These were just some notes on implementation details, they don't really
impact my overall opinion of the RFC. I should also say that I'm not
strongly opposed here, I'm just not convinced this is worthwhile :) The
complexity of the feature would be rather easy to overlook if I felt the
functionality was important.

I myself think one should take into account that this is a feature

that would make PHP stand out even more. Not being a follower of
other languages here :-)

Heh, it's the other way around for me: This just makes me more
apprehensive. Is there some special property of PHP that makes this feature
more relevant to us than other languages? All other mainstream languages do
well without this feature, so why do we need it?

Regards,
Nikita

HI Larry Garfield,

Do you have a plan to further extend this rfc? I mean, what if one
could typecast place holders? Broadly speaking, what if one could
perform some operations, such as arithmetic, bitwise, and type cast as
said above?

$foo = bar((type) ?);
$foo = bar(? & 0xFF);

Best
Hamza Ahmad

Le sam. 19 juin 2021 à 01:41, Benjamin Eberlei kontakt@beberlei.de a
écrit :

On Wed, Jun 16, 2021 at 6:17 PM Larry Garfield larry@garfieldtech.com
wrote:

Hi folks. The vote for the Partial Function Application RFC is now
open,
and will run until 30 June.

https://wiki.php.net/rfc/partial_function_application

Of particular note, a few people had asked about using ...? instead of
...
for the variadic placeholder. In the end we decided not to explore
that,
as Nikita explained off-list it was actually more confusing, not less,
as
it would suggest "placeholder for a variadic" rather than "a
placeholder
that is variadic." Otherwise, it's just more typing. The syntax
choices
section of the RFC has been updated accordingly.

I wanted to explain my no vote on this one.

The examples section shows how every use-case of partials can be done
using
short functions and while this is often a lot more to type (especially if
you mirror the typehints), these extra symbols feel necessary from my POV
to make the code clear that creates a partial.

Especially the ... as "additional" arguments and its various interactions
with ? produce so many different ways of calling something, it feels
unnecessary to me to introduce this complexity to newbies that might come
across use of this functionality. Plus the additional edge cases of
delayed
execution, non-support for named parameters. Its a lot to know to fully
understand this feature.

Given that the functional paradigm isn't widely spread in use across PHP
developers, i am not convinced that we should add more features in this
direction that increase the complexity of understanding the language by
that much. While one could argue that functional paradigm isn't
wide-spread, because these features are missing, it is my believe that
the
majority of PHP developers would still rather prefer imperative coding.

As a thought experiment I tried to think of code in our codebase that we
could convert to PFA once we migrated to 8.1 and there just isn't that
much. This is very different to short functions, nullabilty operator and
other "glue" / sugar proposals that were added to the language lately,
which a lot of existing code benefits from and existing code could be
converted automatically to them using phpcs/phpcbf rules.

I also am wary of the future after this RFC, as it states it is the
launching pad to another attempt at the Pipe Operator, which also
proposes
to do a thing (calling functions) in a completly new way that will be
hard
for beginners. I hope we don't add both these features to keep the
language
smaller in this aspect of how functions are called.

I second Benjamin's opinion, hence my choice of voting "no" as well.

Every new feature we add adds an extra layer of complexity in an
exponential way, next new features/syntax have to deal with existing ones.
The problem being solved with PFA, including how frequent it could be
useful in PHP's ecosystem, does not, IMHO, counterbalance with the
increased code complexity.

-Patrick

Just to offer a counter perspective since the assertion was made that
partial functions would be hard for beginners.

I believe beginners will have a harder time comprehending closures, and
especially short closures, than partial functions. And especially for
the use-cases which are likely to be more common, none of which are any
more "functional" in nature than PHP already is. The use-cases I think
will be more common? Calling any of the existing built-in PHP functions
that accept a callable as a parameter.

I am no expert on beginners but I did teach beginning programmers in a
classroom setting for a decade. One of the biggest stumbling blocks I
have found for beginners is excessive syntax that looks complex. Many
of the concepts themselves are less difficult for beginners to
understand.

So, in my experience it will be easier for newbies to understand this,
for example:

array_map( $this->sanitize_value(?), $values );

Rather that this:

array_map( fn($value) => $this->sanitize_value($value), $values );

The latter just has more sigils to grok than the former, and from what
I've seen with newbies when you throw too many sigils at them they
quickly move into a learned helpless state and think that it will be
too complicated for them to understand.

Frankly, that's the impression I get as well.

Any time PHP developers are discussing "what newbies find easy," there's a very, very strong bias toward "newbies are writing procedural code like it's 1990" and anything more complex than that is "advanced and confusing." And it always seems to be said by people who either are themselves primarily procedural programmers or started off as such, years ago. That bias leaks into their thinking about "what newbies think."

The thing is, new developers don't think anything. There's nothing intrinsically more "natural" about procedural code vs functional code, or OOP code, or whatever other paradigm. They're all artificial as far as the brain is concerned. People who start off in an OOP language, and are taught OOP from the get-go, are just as confused by procedural code as someone who learned procedural is when viewing OOP for the first time. Same for people who start in FP languages.

To hold that functional concepts or OOP concepts or whatever are "more advanced" and "less newbie friendly" than procedural is to buy into the rather damaging elitism that some in FP or strictly OOP languages have; that they're somehow "higher order developers" because they write in LISP, or Clojure, or Haskell, or whatever. That is simply self-serving elitism, but it is really easy for those in more conventional languages to inadvertently buy into that elitism.

The trend in recent years has been very clearly toward multi-paradigm languages. Even the world's most widely used language today, Javascript, is now a procedural/OOP/functional hybrid. It has its warts along the way (as does PHP), but if anything, given the number of people who get their start in Javascript these days I wager they'd expect to have easy to use higher-order functions, because Javascript does. In Javascript they would just write a function name directly, but "Oh, I have to put (?) after it" is a very short jump.

In some ways, we're still playing catch up, and PFA is an important part of that catch up.

Let's not limit PHP's potential reach with new-to-PHP developers by acting like they're all still late-90s new-to-development. These days, odds are good they're Javascript developers looking to move server-side, and they'll already have exposure to many functional concepts even if they don't know them as such explicitly.

For them, the common, non-pathological cases of PFA should be readily obvious to read and understand.

--Larry Garfield

Le 24 juin 2021 à 18:02, Larry Garfield larry@garfieldtech.com a écrit :

Hi folks. The vote for the Partial Function Application RFC is now
open, and will run until 30 June.

https://wiki.php.net/rfc/partial_function_application

Of particular note, a few people had asked about using ...? instead of
... for the variadic placeholder. In the end we decided not to explore
that, as Nikita explained off-list it was actually more confusing, not
less, as it would suggest "placeholder for a variadic" rather than "a
placeholder that is variadic." Otherwise, it's just more typing. The
syntax choices section of the RFC has been updated accordingly.

Since some people still don't grok the use cases, I've written a blog post to make the case for them better than a detail-oriented RFC can.

https://peakd.com/hive-168588/@crell/the-case-for-partials-and-pipes-in-php

There has also been some positive Twitter chatter, as well as the level of +1s on that post (which is, I think, the highest of any PHP post I've had on there, ever), so I think the demand for it is definitely there in the ecosystem. It's just not people who frequent Internals. :-/

I'd say there are definitely people that want to use partials.

--Larry Garfield

--

To unsubscribe, visit: https://www.php.net/unsub.php

Hi,

In the blog post, you are not fair when comparing:

Request::fromGlobals()
   |> normalize_path(?)
   |> oauth_check(?)
   |> parse_body($dbconn, ?)
   |> $resolver->resolveController(?)
   |> controller_caller(?)
   |> response_handler(?, $theme_system)
   |> $add_cache_headers(?)
   |> send_response(?)
;

with:

Request::fromGlobals()
  |> fn(ServerRequestInterface $request): ServerRequestInterface => normalize_path($request)
  |> fn(ServerRequestInterface $request): ServerRequestInterface => oauth_check($request)
  |> fn(ServerRequestInterface $request): ServerRequestInterface => parse_body($dbconn, $request)
  |> fn(ServerRequestInterface $request): ServerRequestInterface => $resolver->resolveController($request)
  |> fn(ServerRequestInterface $request): ResponseInterface => controller_caller($request)
  |> fn(ResponseInterface $response): ResponseInterface => response_handler($response, $theme_system)
  |> fn(ResponseInterface $response): ResponseInterface => $add_cache_headers($response)
  |> fn(ResponseInterface $response): ResponseInterface => send_response($response)
;

I would write it the following way:

Request::fromGlobals()
  |> fn($_) => normalize_path($_)
  |> fn($_) => oauth_check($_)
  |> fn($_) => parse_body($dbconn, $_)
  |> fn($_) => $resolver->resolveController($_)
  |> fn($_) => controller_caller($_)
  |> fn($_) => response_handler($_, $theme_system)
  |> fn($_) => $add_cache_headers($_)
  |> fn($_) => send_response($_)
;

The version with partials is still better as it has less grawlix, but the difference between the two is considerably reduced. Style can make a big difference in readability.

Also, without pipes or partials, it could be written as:

$_ = Request::fromGlobals();
$_ = normalize_path($_);
$_ = oauth_check($_);
$_ = parse_body($dbconn, $_);
$_ = $resolver->resolveController($_);
$_ = controller_caller($_);
$_ = response_handler($_, $theme_system);
$_ = $add_cache_headers($_);
send_response($_);

where my $_s play the role of your ?s.

(I still do find that pipes and partials would be nice additions, but it is not something that I am desperately craving after.)

—Claude

Ah, but you've uncovered one of the benefits of partials -- they
propagate type information. Of course, in this case you would hit an
error immediately so it wouldn't make that much of a difference, but
there are cases where it would matter, such as when being used in
callbacks to array_map and such.

Hi folks. The vote for the Partial Function Application RFC is now
open, and will run until 30 June.

https://wiki.php.net/rfc/partial_function_application

Of particular note, a few people had asked about using ...? instead of
... for the variadic placeholder. In the end we decided not to explore
that, as Nikita explained off-list it was actually more confusing, not
less, as it would suggest "placeholder for a variadic" rather than "a
placeholder that is variadic." Otherwise, it's just more typing. The
syntax choices section of the RFC has been updated accordingly.

Since some people still don't grok the use cases, I've written a blog post
to make the case for them better than a detail-oriented RFC can.

https://peakd.com/hive-168588/@crell/the-case-for-partials-and-pipes-in-php

There has also been some positive Twitter chatter, as well as the level of
+1s on that post (which is, I think, the highest of any PHP post I've had
on there, ever), so I think the demand for it is definitely there in the
ecosystem. It's just not people who frequent Internals. :-/

I'd say there are definitely people that want to use partials.

--Larry Garfield

--

To unsubscribe, visit: https://www.php.net/unsub.php

Out of curiosity, what would it take to implement function aliasing in PHP?
To enable a limited form of pipes, like foo |> bar.

Olle

We probably could special case it for pipes; it's more of a matter if
we should. But, to do it generally so that things like
array_map(strlen, $arr) work is not trivial. The main issue is that
different symbol types have separate "tables", if you will. The engine
decides to look in one bucket or another based on the syntax. In this
case, based on syntax the engine will look in the constant table for
strlen, as strlen in array_map(strlen, $arr) is a constant
lookup by syntax.

If we want it to fall-back to looking in other tables, then we'd have
to deal with various challenges:

1. We have to deal with symbol collisions that exist today somehow,
   such as if strlen exists both as a function and a constant, or if
   $this->count exists as both a property and a method. I would prefer
   to do the simple thing and forbid collisions, but there are other
   strategies.
2. How do we handle the fact that different symbol types behave
   differently in namespaces when the symbol doesn't exist?
3. Also, how do we handle differences in case sensitivity between symbol types?

Personally, I think it's worth it to change all of these things,
because it could also give us function and constant autoloading. Of
course, we'd have to get 2/3 of voters to agree on solutions to these
things, which probably includes some backward-compatibility breaks so
that might be difficult. But, nobody has tried so maybe not.

(Extracted from the "Pipe Operator, take 2" thread)

On Tue, Jun 29, 2021 at 12:54 AM Larry Garfield larry@garfieldtech.com
wrote:

Would a slimmed down version have more support? How about removing the
variadic operator, and let the user manually add the lambda for those
cases?

I talked with Joe about this, and the answer is no. Most of the
complexity comes from the initial "this is a function call, oops no, it's a
partial call so we switch to doing that instead", which ends up interacting
with the engine in a lot of different places.

Are you saying that the implementation complexity is mainly due to chosing
a syntax that looks like a function call?
If yes, is it also the case for the "First-class callable syntax" RFC?
And does it mean that a different syntax (e.g. with a prefix operator)
would result in a simpler implementation?

From what I understand from Joe, most of the complexity comes from
producing something that isn't a closure but shares the same interface
as a closure (at least that's what it would be in PHP terms), which
then requires lots of special handling throughout the engine. I don't
fully understand it all myself, TBH.

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

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



> 2021-06-30 19:10 GMT+02:00, Larry Garfield <larry@garfieldtech.com>:
>> 
>>
>>>  > 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
>
> --
> 
> To unsubscribe, visit: https://www.php.net/unsub.php