Re: [PHP-DEV] Re: Straw poll: Places to allow function calls in constant expressions
> The original motivation was, IIRC, to initialize class constants with an
> expression.
> Following KISS, I feel we should constrain our efforts to that scope, and
> that's how I voted:
> "Yes" on class constants and static members, "No" on everything else.
I'd also personally found the `static $x = null; if ($x === null) { $x =
some_fn(); }` pattern inconvenient and wanted that to be just `static $x =
some_fn();` to make the initial value `some_fn()` if possible. It also seemed
more readable (e.g. doesn't matter if some_fn() can be constant).
My personal use case for parameter defaults and global constants isn't as
strong (especially with define()),
but it's still something I'd want.
- I'd be able to use `private const FOO_DEFAULT = array_keys(...); function
foo($x = FOO_DEFAULT) {}` if constants did pass, so that's less off a concern,
and ensures clear that the expression is only evaluated once, so it might
be a better place to start with.
> As for implementation, we must manage the complexity.
> I'm a hard "No" on restricting use to an arbitrary, variable list of blessed
> functions.
> It's a dev UX nightmare to include a bevy of array_* functions but no str*
> functions.
If the RFC succeeded with a whitelist, I'd planned to create RFCs to add to the
whitelist.
Locale dependency of string functions was the reason for leaving it out
initially, since that may also be a hard "no" for others.
> Consequently, the only way to safely initialize class constants and static
> members is at run-time, and I can only think of one way to do it.
> Apologies if this has already been suggested: taking a cue from C#, a static
> class constructor ([1])
> would allow us to have expression-initialized constants and static members.
> class Config {
> public const URL = null; // compile time initialization
> protected static $mtime = null; // compile time initialization
> private static function __constructStatic() {
> $env = json_decode(file_get_contents('config.json'));
> self::URL = $env->url;
> self::$mtime = filemtime('config.json');
>}
>public function reload() {
>if (self::$mtime < filemtime('config.json'))
>self::__constructStatic();
>}
>}
> }
>
> echo Config::URL; // assert: runtime has already called _constructStatic
> $config = new Config; // assert: __constructStatic called only once by runtime
> $config->reload(); // instance may call its own static constructor
?>
This seems to allow the same functionality my RFC would allow, in a slightly
different way.
I didn't go with that syntax because it'd move the values of the
constants/properties away from the declaration.
Also, if `json_decode()` threw, then there would never be a way for a PHP
implementation to initialize `self::$mtime` in that example, even though
they're unrelated in how they're initialized there.
Allowing calling `__constructStatic` multiple times (thus assigning to the
**const** `self::URL` multiple times) would be a significant change to php
internals, and out of the scope of this RFC
https://wiki.php.net/rfc/calls_in_constant_expressions_poll ("Put the RFC(Poll)
URL into all your replies.")
- Tyson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Straw poll: Places to allow function calls in constant expressions
> On Feb 19, 2020, at 2:00 PM, Bishop Bettini wrote:
>
> Consequently, the only way to safely initialize class constants and static
> members is at run-time, and I can only think of one way to do it. Apologies
> if this has already been suggested: taking a cue from C#, a static class
> constructor ([1]) would allow us to have expression-initialized constants
> and static members.
>
> class Config {
>public const URL = null; // compile time initialization
>protected static $mtime = null; // compile time initialization
>private static function __constructStatic() {
>$env = json_decode(file_get_contents('config.json'));
>self::URL = $env->url;
>self::$mtime = filemtime('config.json');
> }
> public function reload() {
> if (self::$mtime < filemtime('config.json'))
> self::__constructStatic();
> }
> }
> }
>
> echo Config::URL; // assert: runtime has already called _constructStatic
> $config = new Config; // assert: __constructStatic called only once by
> runtime
> $config->reload(); // instance may call its own static constructor
> ?>
>
> Trying to do the same for global constants, static variables, or function
> default parameters resists a similar initialization mechanism because we
> don't have defined common entry point analogues. If we had a main(), or if
> we had framed @before decorators, we could do something similar, but we
> don't -- so I feel we should leave these off the table.
For different reasons than this RFC I have wanted a static class constructor
for a really long time.
I hope this is something we can seriously consider. Thanks Bishop for
proposing it.
-Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Straw poll: Places to allow function calls in constant expressions
On Wed, Feb 19, 2020 at 12:58 PM tyson andre
wrote:
> Hi internals,
>
> > I've created a straw poll at
> https://wiki.php.net/rfc/calls_in_constant_expressions_poll , to measure
> interest in allowing calls in different types of constant expressions.
> > If there aren't any problems with the poll structure or rules preventing
> creating a poll, I was going to add it to the rfc index page and move it to
> voting.
>
> This straw poll has been moved to voting and added to the rfc index page.
> The poll will be closed on March 4th.
>
The original motivation was, IIRC, to initialize class constants with an
expression. Following KISS, I feel we should constrain our efforts to that
scope, and that's how I voted: "Yes" on class constants and static members,
"No" on everything else.
As for implementation, we must manage the complexity. I'm a hard "No" on
restricting use to an arbitrary, variable list of blessed functions. It's a
dev UX nightmare to include a bevy of array_* functions but no str*
functions.
Consequently, the only way to safely initialize class constants and static
members is at run-time, and I can only think of one way to do it. Apologies
if this has already been suggested: taking a cue from C#, a static class
constructor ([1]) would allow us to have expression-initialized constants
and static members.
url;
self::$mtime = filemtime('config.json');
}
public function reload() {
if (self::$mtime < filemtime('config.json'))
self::__constructStatic();
}
}
}
echo Config::URL; // assert: runtime has already called _constructStatic
$config = new Config; // assert: __constructStatic called only once by
runtime
$config->reload(); // instance may call its own static constructor
?>
Trying to do the same for global constants, static variables, or function
default parameters resists a similar initialization mechanism because we
don't have defined common entry point analogues. If we had a main(), or if
we had framed @before decorators, we could do something similar, but we
don't -- so I feel we should leave these off the table.
Thank you, Tyson, for taking the time to progress this feature.
[1]:
https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/static-constructors
[PHP-DEV] Re: Straw poll: Places to allow function calls in constant expressions
Hi internals, > I've created a straw poll at > https://wiki.php.net/rfc/calls_in_constant_expressions_poll , to measure > interest in allowing calls in different types of constant expressions. > If there aren't any problems with the poll structure or rules preventing > creating a poll, I was going to add it to the rfc index page and move it to > voting. This straw poll has been moved to voting and added to the rfc index page. The poll will be closed on March 4th. Thanks, - Tyson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Straw poll: Places to allow function calls in constant expressions
> > I've created a straw poll at > > https://wiki.php.net/rfc/calls_in_constant_expressions_poll , > > to measure interest in allowing calls in different types of constant > > expressions. > > I've yet to make my mind up for most circumstances, although I'm leaning towards a general "No". > > What I can't express on this strawpoll though, is that I would > unequivocally vote against "any function or method call" in all > circumstances. Thanks for the feedback. When reading the poll results, I was planning to interpret both "whitelist of function calls" and "no" as a plan for a "no" vote on any RFC I would write that did allow "any function or method call", in the absence of any response otherwise. You definitely have a point that it doesn't include complicated reasons such as "yes on whitelist, less preferably yes on any function/method", or "yes on any function, definitely no on a whitelist". But I felt like adding too many voting polls or options would discourage responding to a request for quick feedback, and that any more detailed feedback such as this or implementation details could be included in this email thread. - Tyson. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Straw poll: Places to allow function calls in constant expressions
On 17/02/2020 02:08, tyson andre wrote: I've created a straw poll at https://wiki.php.net/rfc/calls_in_constant_expressions_poll , to measure interest in allowing calls in different types of constant expressions. I've yet to make my mind up for most circumstances, although I'm leaning towards a general "No". What I can't express on this strawpoll though, is that I would unequivocally vote against "any function or method call" in all circumstances. -- Mark Randall marand...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
