[PHP-DEV] FFI::new(), FFI::type(), FFI::cast() statically RFC is stupid implementation

[chopins xiao]

Haven't been paying attention for a while and found that FFI::new(), 
FFI::type(), FFI::cast()statically are marked as deprecated, which is a bad 
implementation.
Suggesting in 
RFC:https://wiki.php.net/rfc/deprecate_functions_with_overloaded_signatures#fficast_ffinew_and_ffitype
 that you should replace static calls with instances is a stupid suggestion. 
This RFC was implemented on July 18, 2023 in 
https://github.com/php/php-src/commit/4acf0084dcd63ec369a610ec966db33f322694c8. 
On this issue, I submitted a proposal on May 14, 2022 
https://github.com/php/php-src/issues/8554 here.

Here's why it's not advisable to remove static:

  1.  The non-static call through the FFI instance is the C function, and the 
new(), type(), cast() are PHP class methods, which is a very strange API 
implementation, and these three function names occupy the C function that may 
exist. Also, the function zend_ffi_get_func implementation in ffi.c is not so 
good on its own.
  2.  When you need to get non-PHP type data, you can get it directly through 
static new without getting an FFI object instance first. This is useful when 
using only C primitive data types, without thinking about performance, and 
without calling C libraries.
  3.  PHP programmers aren't all fools, PHP programmers who can use the FFI 
interface must have the relevant skills.

Re: [PHP-DEV] Renaming "strict types" to "scalar type coercion"

[Rowan Tommins [IMSoP]]

On 19/06/2024 09:30, Robert Landers wrote:

Essentially, an int could become a float (within some limits),
but a float can only become an int if it is an int itself. The same
concept of a string, where "123test" couldn't become a number because
"test" would be lost.



Both of these are already covered, at least as far as parameter/return 
types, which is what "strict_types" controls...


'123test' is rejected, not coerced to int, as of 8.0: https://3v4l.org/nvbML

Losing precision on a float-to-int is deprecated, so will presumably 
error as of 9.0: https://3v4l.org/vvD2e



--
Rowan Tommins
[IMSoP]

Re: [PHP-DEV] [RFC] Static Constructor

[Mike Schinkel]

> On Jun 19, 2024, at 2:36 PM, Ilija Tovilo  wrote:
> On Wed, Jun 19, 2024 at 2:34 PM Erick de Azevedo Lima
>  wrote:
>> New expressions continue to not be supported in (static and non-static) 
>> property initializers and class constant initializers. The reasons for this 
>> are twofold:
>> [snip]
>> For static property initializers and class constant initializers a different 
>> evaluation order issue arises. Currently, these initializers are evaluated 
>> lazily the first time a class is used in a certain way (e.g. instantiated). 
>> Once initializers can contain potentially side-effecting expressions, it 
>> would be preferable to have a more well-defined evaluation order. However, 
>> the straightforward approach of evaluating initilizers when the class is 
>> declared would break certain existing code patterns. In particular, 
>> referencing a class that is declared later in the same file would no longer 
>> work.
> 
> Lazy evaluation might be ok if order is clearly defined.

Consider that some uses for a static function need to always occur no matter 
whether or not any other method of the class is called. My previous email [1] 
covered several.

Here [2] is a discussion on StackOverflow of "hooks" that should be eagerly 
loaded.

Thus I think it important that if lazy evaluation is used for static 
initializers then it should be an option, and ideally one that is opt-in vs. 
opt-out, e.g.:

class Foo {
private static lazy function __staticConstruct():void {
// Do initialization stuff here
}
}


-Mike
[1] https://externals.io/message/123675#123684 

[2] https://stackoverflow.com/a/2400206/102699 
 

Re: [PHP-DEV] [RFC] [discussion] Correctly name the rounding mode and make it an Enum

[Claude Pache]

Hi, 

Naming is hard, for sure. Here is my review. I find the names mostly 
reasonable, except Round::PositiveInfinity and Round::NegativeInfinity. I will 
discuss Round::PositiveInfinity.

First:

> I've discussed this with Saki. In that case the `HalfEven` and `HalfOdd` 
> modes would also need to be renamed to `HalfTowardsEven` and `HalfTowardsOdd`

For me, the implied preposition in `HalfEven` is “to”, not “towards”. In other 
words, in the HalfEven mode, a half-number is replaced with the nearest even 
integer; it is not replaced with a integer *in the direction of* (or: 
*towards*) an even integer. So, `Round::HalfEven` is fine; but 
`Round::PositiveInfinity` does not make much sense to me, as the number is not 
rounded to +∞, but towards +∞.

---

Second, “TowardsPositiveInfinity” is just a mouthful synonym for “Up”. You 
could just name it:

Round::Up

At this point, you may invoke either Hamming or Levenshtein and compare it 
negatively with `Round::HalfUp`. Yes there is a risk a confusion (and I do 
think that such a name is suboptimal for this reason), but the confusion is not 
just caused by the short Levenshtein distance. That brings to the most 
important part of my review. 

---

In my opinion, the most important criterion for a good name is:

The name must be clear for itself, not just when comparing it with other ones.

The problem with `Round::Up` (or `Round::[Towards]PositiveInfinity`), when you 
first encounter it, is that it is relatively easy to mistakingly assume that it 
is a “half-*” mode, and to erroneously  interpret it as `Round::HalfUp` (or, 
its synonym `Round::HalfTowardsPositiveInfinity`).

But that the converse is false: it is impossible to interpret `Round::HalfUp` 
as if it were `Round::Up` (or `Round::TowardsPositiveInfinity`), because of the 
distinctive “Half” token that immediately indicate the right interpretation.

So, the best way to disambiguate `Round::Up` from `Round::HalfUp`, is not to 
replace “Up” with some creative synonym, but to add a distinctive token that 
plays the role of — and contrasts with — “Half”. I don’t know if the following 
suggestion makes sense for you, but it is the one I have found:

Round::FullUp

-

That said, I think that there is an even better option. I know you will not 
like it, but bear with me. I sincerely think that the best name is just:

Round::Ceiling

It is short, distinctive, and standard across the computing industry.

Yes, this name is idiosyncratic to English and not used in several other 
(natural) languages, and if you don’t know English, you will not grasp the 
metaphor and have to just learn it. However, whatever other name you invent, 
you *have* to learn “ceil” anyway, because you *will* encounter it sooner or 
later. Many common (programming) languages, including JavaScript, C++, Java, 
Python, have a `ceil` function. Even if you manage not to learn any of those 
and to code in PHP only, you are at risk to stumble on its built-in `ceil(...)` 
function, or its newly-introduced `bcceil(...)` variant.

Therefore, unless we find a name that is *really* good, I suggest to not fall 
into the NIH syndrome, and not to force users to learn another name *in 
addition to* “ceiling”.

-

For the same reason, `Round::TowardsZero` (suboptimal, because confusable with 
`Round::HalfTowardsZero`) could be replaced with: `Round::Truncate`.


—Claude

Re: [PHP-DEV] [RFC] Static Constructor

[Ilija Tovilo]

Hi Erick

On Wed, Jun 19, 2024 at 2:34 PM Erick de Azevedo Lima
 wrote:
>
> You can read the RFC here:
> https://wiki.php.net/rfc/static_constructor

I see that you're using zend_class_init_statics() as a hook to call
__static_construct(). This makes the initialization order
unpredictable, because static properties are initialized lazily when
the class is first used (when instantiated, when accessing constants,
etc.). Essentially, this recreates the same problem described in the
"new in initializer" RFC:

https://wiki.php.net/rfc/new_in_initializers#unsupported_positions

> New expressions continue to not be supported in (static and non-static) 
> property initializers and class constant initializers. The reasons for this 
> are twofold:
> [snip]
> For static property initializers and class constant initializers a different 
> evaluation order issue arises. Currently, these initializers are evaluated 
> lazily the first time a class is used in a certain way (e.g. instantiated). 
> Once initializers can contain potentially side-effecting expressions, it 
> would be preferable to have a more well-defined evaluation order. However, 
> the straightforward approach of evaluating initilizers when the class is 
> declared would break certain existing code patterns. In particular, 
> referencing a class that is declared later in the same file would no longer 
> work.

Lazy evaluation might be ok if order is clearly defined. Making the
order undefined makes it hard (or impossible) to understand which
symbols declared in the current file may be used from
__static_construct(). The alternative mentioned above (calling
__static_construct() at class-declaration-time) likely breaks too much
existing code (because it would also require calling static
initializers just before that, which may reference symbols declared
later on), and is further complicated by early-binding. I'm not sure
what the best approach is here.

Ilija

Re: [PHP-DEV] [RFC] Static Constructor

[Tim Düsterhus]

Hi

On 6/19/24 16:03, Erick de Azevedo Lima wrote:

I have considered some names, actually. I just chose this one for the
implementation because
I tried to design it to be as close as possible to the C# implementation
and they call it "static constructor".
But the name can be changed to another one without any problem at all.


I would suggest `__constructStatic()`. This matches the existing naming 
pattern of `__callStatic()` being the companion to `__call()`.


Best regards
Tim Düsterhus

Re: [PHP-DEV] [RFC] Static Constructor

[Mike Schinkel]

> On Jun 19, 2024, at 8:33 AM, Erick de Azevedo Lima  > wrote:
> 
> Hello everybody.
> 
> I found myself wanting this feature (that I first encountered when 
> programming in C#) for removing a workaround from a codebase I work from time 
> to time.
> I searched internals and found a discussion from almost a decade ago. That 
> discussion did not end well, mostly because of insulting accusations.
> I then decided to do some research on this subject and found out that it's a 
> pretty common feature in other OOP languages.
> Also, as I started studying the php-src  (and missed the days when I used to 
> program in C in my main job), I decided to do an implementation myself even 
> before presenting the RFC.
> The implementation link can also be found at the RFC.
> 
> You can read the RFC here:
> https://wiki.php.net/rfc/static_constructor 
> 
> 
> Regards,
> 
> Erick

1. I noticed you did not include an example for Go so I wrote one up for you in 
a Go playground. Hopefully you can include Go's approach in your RFC?

> https://goplay.tools/snippet/6lvAQdye9P9 
> 
2. Also, in the past I made frequent use of "on_load()" methods that I would 
call immediately after the class code. I always wanted a static initializer — 
and even discussed it with Ben Ramsay at an after-event for Atlanta PHP meetup 
years ago — but I never proposed in as an RFC and cannot remember if I ever 
discussed here on the list.

Even though I no longer actively use or maintain the following library I wanted 
to provide you with links for each of the different use-case where I had an 
`on_load()` method and would have used a static initializer had it been 
available in hopes they may inspire you to enhance your RFC with new use-cases. 
I am also sharing for others to see the different use-cases:

- https://github.com/wplib/wplib/blob/master/wplib.php#L142 

- https://github.com/wplib/wplib/blob/master/modules/posts/posts.php#L43 
 
- https://github.com/wplib/wplib/blob/master/modules/theme/theme.php#L14 

- 
https://github.com/wplib/wplib/blob/master/modules/role-administrator/role-administrator.php#L35
 

- 
https://github.com/wplib/wplib/blob/master/modules/roles/includes/class-role-module-base.php#L33
 

- 
https://github.com/wplib/wplib/blob/master/modules/commit-reviser/commit-reviser.php#L13
 

- 
https://github.com/wplib/wplib/blob/master/modules/helpers-html/helpers-html.php#L16
 

 

3. One thing about "best practices" for static initializers. When using a 
package-level variable in Go initializations and for those PHP static classes 
with `on_load()` methods I found it problematic to add anything that could fail 
in a reasonable use-case, and I would recommend that this would become the 
advice given as a best practice for using static initializers. 

In my PHP examples above I do happen to assume the database is open and exists 
but only because the library is for use with WordPress as a must-load plugin, 
and if the database is not available my plugin will never get loaded.

In Go I never use database access code or remote API calls, or anything that 
could generate an error. I instead create "initialize" methods and call them 
explicitly in `main()` or some other func that `main()` calls.

In PHP you can have a syntax error at runtime, but in that case it will error 
as soon as you try to autoload the PHP file so I do not think syntax errors 
should be real concern here, only runtime errors.

4. To elaborate more about "best practices" where I see static initializers 
being especially valuable it when you want to initialize immutable data, and 
especially when that data is in complex form such as an object vs. just a 
simple value. Here is one such example of this which initializes the default 
labels for a WordPress post-type: 
https://github.com/wplib/wplib/blob/master/modules/posts/posts.php#L54-L64 
 

5. Another use-case is registering "hooks" defined by a framework, such as the 
`wp_loaded` hook in WordPress: 
https://github.com/wplib/wplib/blob/master/modules/posts/posts.php#L68C28-L68C37
 

 

6. Yes another use-case would be to make a framework more robust and to provide 
guidanc

Re: [PHP-DEV] Renaming "strict types" to "scalar type coercion"

[Mike Schinkel]

> On Jun 18, 2024, at 5:04 PM, David Gebler  wrote:
> 
> On Tue, 18 Jun 2024, 17:40 Robert Landers,  > wrote:
> Hello internals,
> 
> Many, many people start their files fairly religiously:
> 
>  
> and I say "religiously" because from talking to people in real life,
> reddit, workplaces, etc, very few php programmers actually know what
> this does but do it nonetheless. 
> 
> I think there's almost certainly a degree of truth, not just in PHP but 
> programming in general, in the idea that there are many people who will 
> blindly follow a convention for no better reason they once heard someone they 
> considered more senior than themselves say the words "best practice"


There is a notable term for that: "Cargo Cult Programming":

https://en.wikipedia.org/wiki/Cargo_cult_programming 


#fwiw

-Mike

Re: [PHP-DEV] Renaming "strict types" to "scalar type coercion"

[Robert Landers]

On Wed, Jun 19, 2024 at 5:43 PM Sebastian Bergmann  wrote:
>
> Am 19.06.2024 um 17:34 schrieb Larry Garfield:
> > Also, as someone who does put every file into strict mode as a matter of 
> > course, and appreciates the many languages that do not even have a concept 
> > of non-strict mode (like Go or Rust), I really don't appreciate the 
> > backhanded comments in this thread about people who, you know, care about 
> > type safety.  (Something that weak mode, when it was introduced in PHP 7, 
> > only marginally provided if at all.)  Strict mode prevents bugs, full stop, 
> > and we should not fault anyone for applying that bug-stopper tool liberally.
>
> What Larry and Gina said.

Strange, I don't have an email from Larry! But I suspect it will show
up eventually... I look forward to it!

I'll go ahead and risk an out-of-context reply, but FWIW, it goes both
ways :) People get irrational about this topic, either for-or-against.

In any case, there is not any "type safety" in PHP because PHP doesn't
know something is the wrong type until runtime. Further, it clearly
doesn't stop bugs, otherwise we'd all be out of a job by now.

Robert Landers
Software Engineer
Utrecht NL

Re: [PHP-DEV] Renaming "strict types" to "scalar type coercion"

[Sebastian Bergmann]

Am 19.06.2024 um 17:34 schrieb Larry Garfield:

Also, as someone who does put every file into strict mode as a matter of 
course, and appreciates the many languages that do not even have a concept of 
non-strict mode (like Go or Rust), I really don't appreciate the backhanded 
comments in this thread about people who, you know, care about type safety.  
(Something that weak mode, when it was introduced in PHP 7, only marginally 
provided if at all.)  Strict mode prevents bugs, full stop, and we should not 
fault anyone for applying that bug-stopper tool liberally.


What Larry and Gina said.

Re: [PHP-DEV] Renaming "strict types" to "scalar type coercion"

[Larry Garfield]

On Wed, Jun 19, 2024, at 10:07 AM, Gina P. Banyard wrote:
> On Tuesday, 18 June 2024 at 17:37, Robert Landers 
>  wrote:
>
>> Hello internals,
>> 
>> [...]
>> 
>> What are your thoughts?
>
> As self-proclaimed leading expert on PHP type juggling.
> That it is a terrible idea with no gains whatsoever.
> Renaming the declare statement does not improve the situation.
>
>> PS. Personally, I would rather unify non-strict and strict in some way
>> that makes sense ... so, that route sounds nice too.
>
> See my old meta RFC: https://github.com/Girgias/unify-typing-modes-rfc
>
> It is a somewhat known hot take from mine that I think the strict_type 
> declare statement was a mistake. [1]
> Mainly because it affects barely nothing in regard to the engine.
>
> I have written/co-authored multiple RFCs over the years to make the 
> default coercion mode less whack. [2][3][4][5][6][7]
> And my container/offset RFC is in the same vein [8] which lead me into 
> a different rabbit hole then the one I was expecting to explore which 
> is addressing PHP's weird comparison semantics. [9]
>
> Therefore, I would rather we focus on *actually* fixing PHP's 
> semantics, than arguing about changing the name of something that 
> shouldn't really exist in the first place.
>
>
> Best regards,
>
> Gina P. Banyard
>
>
> [1] Slide 68 of my PHP UK talk "PHP's Type System Dissected": 
> https://gpb.moe/doc/slides/PHP_Type_System_Talk_PHPUK2023.pdf
> [2] https://wiki.php.net/rfc/saner-numeric-strings
> [3] https://wiki.php.net/rfc/implicit-float-int-deprecate
> [4] https://wiki.php.net/rfc/saner-inc-dec-operators
> [5] https://wiki.php.net/rfc/locale_independent_float_to_string
> [6] https://wiki.php.net/rfc/exit-as-function
> [7] https://wiki.php.net/rfc/deprecate-boolean-string-coercion
> [8] 
> https://github.com/Girgias/php-rfcs/blob/master/container-offset-behaviour.md
> [9] 
> https://github.com/Girgias/php-rfcs/blob/master/comparison-equality-semantics.md

What Gina said.  Renaming the declare key would involve changing *literally 
millions* of files, even if it's over the course of a decade, for little if any 
benefit.

Reducing the delta between weak mode and strict mode to the point that it makes 
little difference (by making the PHP type juggling system less nonsensical and 
random) is a much more achievable goal, and actually has value to justify the 
effort (both for Internals and for people updating their code).

Also, as someone who does put every file into strict mode as a matter of 
course, and appreciates the many languages that do not even have a concept of 
non-strict mode (like Go or Rust), I really don't appreciate the backhanded 
comments in this thread about people who, you know, care about type safety.  
(Something that weak mode, when it was introduced in PHP 7, only marginally 
provided if at all.)  Strict mode prevents bugs, full stop, and we should not 
fault anyone for applying that bug-stopper tool liberally.

--Larry Garfield

Re: [PHP-DEV] [RFC] Static Constructor

[Larry Garfield]

On Wed, Jun 19, 2024, at 7:33 AM, Erick de Azevedo Lima wrote:
> Hello everybody.
>
> I found myself wanting this feature (that I first encountered when 
> programming in C#) for removing a workaround from a codebase I work 
> from time to time.
> I searched internals and found a discussion from almost a decade ago. 
> That discussion did not end well, mostly because of insulting 
> accusations.
> I then decided to do some research on this subject and found out that 
> it's a pretty common feature in other OOP languages.
> Also, as I started studying the php-src  (and missed the days when I 
> used to program in C in my main job), I decided to do an implementation 
> myself even before presenting the RFC.
> The implementation link can also be found at the RFC.
>
> You can read the RFC here:
> https://wiki.php.net/rfc/static_constructor
>
> Regards,
>
> Erick

Unsurprisingly, I have concerns. :-)  Perhaps surprisingly, I don't outright 
hate it.  In particular, the examples you show are on the edge of what I'd 
consider valid use cases: More complex initialization of things like lookup 
tables or "dynamic constants" (like if you wanted to record "now" to use for 
later comparisons).

For that reason, therefore, I don't like the current approach, especially for 
this line: "Programmers have the option to call the __staticConstruct method to 
reset static properties values if desired."

It's screwy enough that you can explicitly call __construct().  I wouldn't want 
to perpetuate that weirdness.  It also feels like it leaves the door open to 
more abuse than is tolerable.  As some of the comments note, half the use cases 
would necessarily involve reaching out to some global state (file system, DB, 
etc.), which is already problematic, especially for testing.

Which also brings up another question: How would one even mock this?  If I 
can't test it, I can't use it.

I would favor the "Java 2" style: Referencing a static method that will be 
called to initialize the value.  That makes it clearer what is happening and 
encourages the intended path/use case: Lazy property initialization.  It also 
avoids a "big blob" function in favor of small, specific functions.  It also 
allows the author to more easily decide if they want to expose that logic to 
child classes for overriding: Make it private or protected, as they prefer.  
(Public I am fine with forbidding.)

A few other notes:

Your examples would be clearer if you leveraged the ??= operator, which would 
reduce your initializeMinDate() methods to a single line.

I also take issue with this paragraph:

> Object-oriented languages like Java, which adhere more strictly to 
> object-oriented principles, include static properties and offer mechanisms 
> for their initialization with non-trivial expressions. Java uses method calls 
> or static blocks for this purpose, as will be demonstrated later in this 
> text, illustrating that even in environments stricter about OOP principles 
> than PHP, static properties are sometimes useful and require appropriate 
> initialization methods. 

Not because other languages are wrong to reference; I do so very frequently, 
and do consider "everyone else is doing it" to be a useful (though not always 
winning) argument.  What I object to is holding up Java as being "stricter 
about OO principles."  OO principles are not a uniform, monolithic thing.  In 
fact, the person who invented the term Object-Oriented has said before that C++ 
and Java are *not* what he had in mind.  "Class based programming" is not what 
OOP was intended to be.  OOP is about "message passing," which is often 
forgotten or misunderstood or ignored.  Also, my day job is now working in 
Kotlin, which means I am faced with a lot of Java code I have to interact with. 
 To be polite, holding up "Java style" design as anything to emulate is... a 
categorical error.

Referencing other languages is fine, do that (and I appreciate that you did; I 
didn't realize this was so common a feature, and that does help make me 
amenable to it), but please do not in any way suggest that Java is the 
definition of "good and proper OOP."  It is extremely not.

I'm still not sold on the idea, but... I think I could be, which is more than I 
expected from the title.

--Larry Garfield

Re: [PHP-DEV] Renaming "strict types" to "scalar type coercion"

[Gina P. Banyard]

On Tuesday, 18 June 2024 at 17:37, Robert Landers  
wrote:

> Hello internals,
> 
> [...]
> 
> What are your thoughts?

As self-proclaimed leading expert on PHP type juggling.
That it is a terrible idea with no gains whatsoever.
Renaming the declare statement does not improve the situation.

> PS. Personally, I would rather unify non-strict and strict in some way
> that makes sense ... so, that route sounds nice too.

See my old meta RFC: https://github.com/Girgias/unify-typing-modes-rfc

It is a somewhat known hot take from mine that I think the strict_type declare 
statement was a mistake. [1]
Mainly because it affects barely nothing in regard to the engine.

I have written/co-authored multiple RFCs over the years to make the default 
coercion mode less whack. [2][3][4][5][6][7]
And my container/offset RFC is in the same vein [8] which lead me into a 
different rabbit hole then the one I was expecting to explore which is 
addressing PHP's weird comparison semantics. [9]

Therefore, I would rather we focus on *actually* fixing PHP's semantics, than 
arguing about changing the name of something that shouldn't really exist in the 
first place.


Best regards,

Gina P. Banyard


[1] Slide 68 of my PHP UK talk "PHP's Type System Dissected": 
https://gpb.moe/doc/slides/PHP_Type_System_Talk_PHPUK2023.pdf
[2] https://wiki.php.net/rfc/saner-numeric-strings
[3] https://wiki.php.net/rfc/implicit-float-int-deprecate
[4] https://wiki.php.net/rfc/saner-inc-dec-operators
[5] https://wiki.php.net/rfc/locale_independent_float_to_string
[6] https://wiki.php.net/rfc/exit-as-function
[7] https://wiki.php.net/rfc/deprecate-boolean-string-coercion
[8] 
https://github.com/Girgias/php-rfcs/blob/master/container-offset-behaviour.md
[9] 
https://github.com/Girgias/php-rfcs/blob/master/comparison-equality-semantics.md

Re: [PHP-DEV] [RFC] Static Constructor

[Erick de Azevedo Lima]

Hi, Michał.

> Have you considered naming it for example shortly `function __static()` ?

I have considered some names, actually. I just chose this one for the
implementation because
I tried to design it to be as close as possible to the C# implementation
and they call it "static constructor".
But the name can be changed to another one without any problem at all.

Regards,
Erick

Re: [PHP-DEV] [RFC] Static Constructor

[Michał Marcin Brzuchalski]

Hi Erick,

śr., 19 cze 2024 o 14:35 Erick de Azevedo Lima 
napisał(a):

> Hello everybody.
>
> I found myself wanting this feature (that I first encountered when
> programming in C#) for removing a workaround from a codebase I work from
> time to time.
> I searched internals and found a discussion from almost a decade ago. That
> discussion did not end well, mostly because of insulting accusations.
> I then decided to do some research on this subject and found out that it's
> a pretty common feature in other OOP languages.
> Also, as I started studying the php-src  (and missed the days when I used
> to program in C in my main job), I decided to do an implementation myself
> even before presenting the RFC.
> The implementation link can also be found at the RFC.
>
> You can read the RFC here:
> https://wiki.php.net/rfc/static_constructor
>
> Regards,
>
> Erick
>

I like the idea of having a static initializer.
I think we could propose a better naming, method name `function
__staticConstructor` is a concatenation of the words static and constructor
while constructor is used as an initializer when building constructing
objects.
Have you considered naming it for example shortly `function __static()` ?
It is somehow similar to https://wiki.php.net/rfc/static_constructor#java
in static-block.

Cheers,
Michał Marcin Brzuchalski

[PHP-DEV] [RFC] Static Constructor

[Erick de Azevedo Lima]

Hello everybody.

I found myself wanting this feature (that I first encountered when
programming in C#) for removing a workaround from a codebase I work from
time to time.
I searched internals and found a discussion from almost a decade ago. That
discussion did not end well, mostly because of insulting accusations.
I then decided to do some research on this subject and found out that it's
a pretty common feature in other OOP languages.
Also, as I started studying the php-src  (and missed the days when I used
to program in C in my main job), I decided to do an implementation myself
even before presenting the RFC.
The implementation link can also be found at the RFC.

You can read the RFC here:
https://wiki.php.net/rfc/static_constructor

Regards,

Erick

Re: [PHP-DEV] Renaming "strict types" to "scalar type coercion"

[Michał Marcin Brzuchalski]

Hi David, Robert,

wt., 18 cze 2024 o 23:12 David Gebler  napisał(a):

> ...
> If I were to support any change to how this feature works for PHP 9, I
> think it would be providing a mechanism to enable it for all files at once,
> maybe either via a .ini setting such as strict_types_default=1 or a new
> declare which applies to all files included or autoloaded from that point
> on, i.e. a declare that could be used as the first line of an entrypoint
> script to make all files in a project have strict typing mode
> enabled/disabled (unless a particular file overrides for its own scope with
> its own declare).
>
> Changing the name to anything other than what it is now, with or without
> flipping the value, just seems like a major BC headache for no gain.
>

I share a similar opinion here.
I'd also rather see a proposal that enables setting the declares outside of
PHP files as this is mostly the same line for every file in most codebases
I work with.

# name it `.phpdeclare` in the execution directory or places where certain
PHP files are read by the PHP interpreter, whatever
```ini
# Global default directives
[*.php]
strict_types = 1
ticks = 0
encoding = UTF-8

# Directives for specific directories
[src/*.php]
strict_types = 1

[tests/*.php]
strict_types = 0

# Directives for specific files
[scripts/setup.php]
strict_types = 1
ticks = 1
```

Just an example, shoving some declares can be set using glob-like patterns
or specific files.
I see potential in this kind of declaring these directives for future
extensions.
This is something I'd love to consider instead of just renaming things we
already have.

Cheers,
Michał Marcin Brzuchalski

Re: [PHP-DEV] Renaming "strict types" to "scalar type coercion"

[David Gebler]

On Wed, 19 Jun 2024, 09:31 Robert Landers,  wrote:

>
> The problem isn't so much this, but in that it has become a dogma to
> "have working types" and trying to explain why they do or do not
> need/want it in the current context becomes a hopeless argument
> because you are attacking their world-view instead of having an
> academic argument
>

If the feature was an RFC being introduced today and you were suggesting
using a better, more descriptive name than strict_types I'd agree.

But it is what it is, it's already in the language, it's already very
widely used and changing the name now won't solve any problem, to whatever
extent that problem exists (which I honestly don't think is very big), of
there being a cohort of users who rigidly stick to using this declare
because they've been told they should always do so, or because they have a
dogmatic opinion about how PHP's type system should work in their ideal of
the language.

Both those groups would continue to use the directive everywhere,
regardless of what it was called. And it's their code, their right. No one
is under any obligation to engage in an academic argument to justify design
decisions in code they own.

-Dave

>

Re: [PHP-DEV] Renaming "strict types" to "scalar type coercion"

[Robert Landers]

On Tue, Jun 18, 2024 at 11:04 PM David Gebler  wrote:
>
> On Tue, 18 Jun 2024, 17:40 Robert Landers,  wrote:
>>
>> Hello internals,
>>
>> Many, many people start their files fairly religiously:
>>
>> >
>> and I say "religiously" because from talking to people in real life,
>> reddit, workplaces, etc, very few php programmers actually know what
>> this does but do it nonetheless.
>
>
> I think there's almost certainly a degree of truth, not just in PHP but 
> programming in general, in the idea that there are many people who will 
> blindly follow a convention for no better reason they once heard someone they 
> considered more senior than themselves say the words "best practice"
>
> But I don't think the meaning of strict_types in PHP is unclear. It's right 
> there in the manual 
> https://www.php.net/manual/en/language.types.declarations.php#language.types.declarations.strict
>
> If anyone is daft enough to use a language feature without referencing what 
> it means or what it does, let them clean up any problems which arise for them 
> as a result.

The problem isn't so much this, but in that it has become a dogma to
"have working types" and trying to explain why they do or do not
need/want it in the current context becomes a hopeless argument
because you are attacking their world-view instead of having an
academic argument.

>
> If I were to support any change to how this feature works for PHP 9, I think 
> it would be providing a mechanism to enable it for all files at once, maybe 
> either via a .ini setting such as strict_types_default=1 or a new declare 
> which applies to all files included or autoloaded from that point on, i.e. a 
> declare that could be used as the first line of an entrypoint script to make 
> all files in a project have strict typing mode enabled/disabled (unless a 
> particular file overrides for its own scope with its own declare).

I've explicitly written code without strict types because, in that
context, I want coercion (mostly when dealing with env vars)
surrounded by files with strict types enabled. Multiple steps would
have to be taken to make this possible (i.e., requiring the setting on
every file, whether off or on), negating the entire feature of having
it set globally. There may be a path where this makes sense, but I
don't think we can get there from here.

>
> Changing the name to anything other than what it is now, with or without 
> flipping the value, just seems like a major BC headache for no gain.
>
> -Dave

Robert Landers
Software Engineer
Utrecht NL

Re: [PHP-DEV] Renaming "strict types" to "scalar type coercion"

[Robert Landers]

On Tue, Jun 18, 2024 at 10:46 PM Rowan Tommins [IMSoP]
 wrote:
>
> On 18/06/2024 17:37, Robert Landers wrote:
>
> One thing is clear is that "strict types" may be a bit of poor word
> choice and gives people a false sense of security that it is "safe" or
> "more correct" when this obviously isn't true.
>
>
> I totally agree with this sentiment. I don't think it should be called 
> "strict", and I don't think it should be "on or off" either.
>
> If I had a time machine, I'd propose something like:
>
> declare(scalar_args=coerce);
> declare(scalar_args=error);
>
> Or perhaps:
>
> declare(coerce_scalar_args=if_safe);
> declare(coerce_scalar_args=never);
>

This is nice. I like it :)

>
>
> But...
>
>
> Thus, I'd like to propose, for PHP 9, simply renaming it...
>
>
> I'm not sure the pain is worth it. We'd have to introduce support gradually, 
> probably not phasing out the old name until 10.0 at the earliest, so you'd 
> just end up with more confusion with people not understanding if they were 
> the same thing, which one to use in which version, etc.
>

I honestly don't know how the deprecation would work, or what makes
sense. Supporting both makes sense and as long as the behavior stays
exactly the same, and they are both set to the same thing, that would
probably be fine for awhile. Is it confusing... I wouldn't find it
confusing unless I was working on something that supported <9 and >9
and eventually 8.x will EoL and then it won't be so confusing anymore.

>
> Perhaps it might even be worth adding a secondary vote to flip the
> default, such that if you want to "old" behavior back
>
>
> You're falling into the same trap you're describing: assuming that 
> strict_types=0 is an "older" mode, or a "worse" one. Both modes were 
> introduced at exactly the same time, as a direct choice to users between two 
> different styles, which had been proposed in competing RFCs.
>
> Changing the default, and the name, but keeping the same behaviour, would 
> just be a huge mess.
>
>
> Personally, I would rather unify non-strict and strict in some way that makes 
> sense
>
>
> I think this is where we should be focussing our attention. We've had some 
> great RFCs over the last few years tightening up some of the weirder excesses 
> of PHP's type juggling system.

I've been mulling this around in my head last night and this morning.
I think I have something that makes sense, based mostly on information
loss. Essentially, an int could become a float (within some limits),
but a float can only become an int if it is an int itself. The same
concept of a string, where "123test" couldn't become a number because
"test" would be lost. Booleans are tricky, but I'd be inclined to keep
it as-is; otherwise, the BC break would be unbearable.

I think something like that would logically make sense. Whether or not
it would be feasible to implement in a performant way, I have no idea
(but it would be nice to clean up that area of the C code since it's a
bit of a tangle, IMHO). Interestingly, we could still do normal
coercion but just warn when there is information loss. Then, people
can ignore/catch those warnings and do whatever they want with them.
If information loss is what you want and you want to get rid of the
warning, you can simply add an explicit cast, but it would be nice
also to adjust casting so you can do

(int|null) $value; // or (?int) $value

so null won't be cast to zero. But that should probably be a totally
separate RFC and out of scope atm.

>
> With a tight enough definition of "numeric string" and other coercible 
> values, I think "mode 0" could be strict enough that "mode 1" wouldn't feel 
> so necessary.
>
> Then again, I was broadly in favour of the original coercive-only proposal 
> for scalar type parameters, and there are those who felt strongly on the 
> other side. The debate was extremely heated, and I'm not in a hurry to reopen 
> it.
>
>
> Regards,
>
> --
> Rowan Tommins
> [IMSoP]

Robert Landers
Software Engineer
Utrecht NL

Re: [PHP-DEV] Renaming "strict types" to "scalar type coercion"

[Robert Landers]

On Tue, Jun 18, 2024 at 9:18 PM Claude Pache  wrote:
>
> Hi,
>
> > One thing is clear is that "strict types" may be a bit of poor word
> > choice and gives people a false sense of security that it is "safe" or
> > "more correct" when this obviously isn't true. Thus, I'd like to
> > propose, for PHP 9, simply renaming it from strict_types to
> > scalar_type_coercion and flipping the value:
> >
> >  >
> > to
> >
> > 
> This not better. Even with `declare(scalar_type_coercion=0)`, there will be 
> scalar type conversions between string and int/float when you add numeric 
> strings or when you concatenate a string with an int.

This is a really good point and worth thinking about. I kinda like
Rowan's suggestion of scalar_args with a usage of string values
instead of integers.

>
> IMO, the real problem with the current name, is that there is no clue that 
> this directive is specifically about arguments and return values in 
> function/method calls.

Yes. This is kinda what I was hoping to address, but like you said,
the name I suggested didn't really capture the semantics either. :D

>
> > Perhaps it might even be worth adding a secondary vote to flip the
> > default, such that if you want to "old" behavior back:
> >
> > 
> That would force to edit thousands of files, ... for exactly zero gain. Have 
> you heard about the Red Queen's race?

This is a pretty simple search-and-replace, so I don't think it would
be hard to update. That being said, there still needs to be a
deprecation strategy that makes sense. As to it being "zero gain,"
words have meaning and choosing the right ones (even if it is years
later) can sometimes be completely worth it and even have monetary
gains.

>
> Moreover, there are many places where it is not possible to add such a 
> declaration. For instance, `array_map(...)`, etc., always use 
> `strict_types=0` when invoking the callback. Changing that would also be a 
> big BC break.
>
> —Claude


Robert Landers
Software Engineer
Utrecht NL