Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:123707 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id 2990A1A009C for ; Thu, 20 Jun 2024 18:39:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1718908818; bh=NMW/2G3ujRToLNLHf43y/oErqrO9aIHVbsCR8hYDoc8=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=HPU/uqU2kLXvDOHywrQMFztM//upA07pR5DJJDgsuoG+0gW49lnEsg4fLQ186R0P6 OpEYh1vzDs1qyFb4F9+zupsDQJ5WCzKevRsCXqjrK8tv37OH+dLwUGRlplsVA39UN7 j2znmMoCmxrznmhCIZSsAsGtSclZba383cIeeXiyFejG9kwu3NF1oYxULNey5ex6Rv L8CJzCUieKIq/F3ZN4UiffqUNq+sXfFNqljvhOdthmEq1mpTmMdo3/O/esYaITUzwe ODMXWLD7STPxdKXhchYeWivWQ3JLXKI3quKzZU1cSg0zNFROEiZSgLr587DWr6rbmP UIsS8HI354MWQ== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id CCD66180572 for ; Thu, 20 Jun 2024 18:40:17 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DMARC_MISSING,HTML_MESSAGE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE, SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: Error (Cannot connect to unix socket '/var/run/clamav/clamd.ctl': connect: Connection refused) X-Envelope-From: Received: from mail-yw1-f174.google.com (mail-yw1-f174.google.com [209.85.128.174]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 20 Jun 2024 18:40:17 +0000 (UTC) Received: by mail-yw1-f174.google.com with SMTP id 00721157ae682-6327e303739so11720397b3.2 for ; Thu, 20 Jun 2024 11:39:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=newclarity-net.20230601.gappssmtp.com; s=20230601; t=1718908742; x=1719513542; darn=lists.php.net; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=YwORW2Q2s+T9TEIbuYU+ROzasGrxTUlv87ROwjTHC4Q=; b=q/ZOVGQXyUMQf28YaBlJCxT3yycTuW7LV5Ei0Srj6jivLSGkXR8aFnIr4uK2i2Ej6w g025e2EINSj1XGxAb94VdKZYLTgNH9yMVIsyleCJx1RCIHdM8rbzfpV4+bsmkcfY9/Aj AyDBaS/Fq15tzFGJO2rgEZ+CiYsQ+aKUEkIX7pqSLa1JOrX+vnC5TaqAVJAzyDGgS/+t jJd8wblIegHZfIYIoQuNZX6Qqec8V5M6uuhrB7I840BnirwOONWfFkvVt4KnDKc4TGxl KQXW5rQisohRk4HJJ/5WelEXE4yiVKlopSaGAxjtDewIHfnZ+Rb9PQ0WVeB0/4GGmEyQ iufw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718908742; x=1719513542; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=YwORW2Q2s+T9TEIbuYU+ROzasGrxTUlv87ROwjTHC4Q=; b=YleUmD4T43m69DoFClK0tOuQ2L5LWro4uOm3OiD9B3KLLKkTrQPxGafLcn5ogJ0kA+ 1QyT12CrCPvRCqQaiICI23BFrKEPzNp/0B8+FCpic7lfzXvz9RZ9b6lVmNDTUhg0nm0L AA/0FZyTCagh2M+moBNPjRvfwBah9S4pm7EiPZdzAqR8atxwWMSeLC/UbJEo/Jb59PbN pbiZwvkTNB5d3oI16YMaUhqsZxqbOJWdJIrX4PJyoNuf5q5qHi4oCXQmK5roCrBf3jeu Kl6dIWsuTakCDEv1cWAWLF7SMf2vdFfwdXD9xb0b09G7HKXIwyuWUiGgf7aNEDoveAAN rZhQ== X-Gm-Message-State: AOJu0YwZYupiUc3ARBqkhOArkhmVPUSRrKFzNhEhp6a7mbvn62zGlQ1v SJR4Goir9e5iJziL3G9XoTlcnIQhV80Y8gReXRzTcpnir6l9z5O5H87opkUeDaQ= X-Google-Smtp-Source: AGHT+IF3lCD7gpwOxb9zt5VpdFCga9y6+ODKLxM4XnTzPHhYRMWRyFAlEwXlHtNlG/yxN1cEG8ILdw== X-Received: by 2002:a0d:fc46:0:b0:618:8e3e:8675 with SMTP id 00721157ae682-63a8dc09bd6mr57614167b3.22.1718908739616; Thu, 20 Jun 2024 11:38:59 -0700 (PDT) Received: from smtpclient.apple (c-98-252-216-111.hsd1.ga.comcast.net. [98.252.216.111]) by smtp.gmail.com with ESMTPSA id 00721157ae682-6311a4461absm31783827b3.92.2024.06.20.11.38.58 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jun 2024 11:38:58 -0700 (PDT) Message-ID: <874508B4-671F-464D-8A5E-294C9B5BED41@newclarity.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_C72E3E3F-4D5B-4FD3-BC79-BE7372E90616" Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.8\)) Subject: Re: [PHP-DEV] [RFC] Static Constructor Date: Thu, 20 Jun 2024 14:38:57 -0400 In-Reply-To: Cc: php internals To: Erick de Azevedo Lima References: X-Mailer: Apple Mail (2.3696.120.41.1.8) From: mike@newclarity.net (Mike Schinkel) --Apple-Mail=_C72E3E3F-4D5B-4FD3-BC79-BE7372E90616 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 20, 2024, at 9:01 AM, Erick de Azevedo Lima = wrot > Mike again: >=20 > > 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. > Yes, I considered this approach before. But then I realized that for = covering the properties initialization,=20 > this already existing lazy loading mechanism would suffice. At the end = of the RFC, > I consider future scope to create an early-init. In my opinion, as it = covers a more general use for this init, > it should be implemented maybe using another magic method, like = "__load" or "__link", > which would be hooks on class loading process and not specific to = static variables initialization Well, that sure is depressing to hear. =20 Looking back on all my uses for static methods, my primary use-case when = building WordPress websites was to wire up hooks thus what excited me = most about the prospect of getting "static constructors" in PHP was for = wiring up said hooks. I get the lack of desire to support a lazy keyword, especially giving = the lazy loading thread happening on the list, and I agree that lazy = loading is better for the use-cases that motivated you, but it is = depressing because the likelihood of someone else after so many years = would have the passion and motivation to propose a `__load` method AND = to have the skills to implement it is slim-to-none IMO. So IOW, a `__load` method it's almost certainly never going to happen. = Such is life I guess. Well at least let me submit a parting bikeshed on the name. Rather than = any form of "construct" can you at least name it `__init` or = `__initialize`? It is not construction, and even in your comment where = you wrote unprompted "...not specific to static variables = initialization" you christened it to be "initialization." P.S. I do think lazy-loading without an explicit keyword will be = counter-intuitive to many, and will result in many a StackOverflow = question asking "Why are my `__staticConstruct` (or `__init` as = proposed) methods not being called?!?" So if it were me I would = implement them w/o default lazy loading so there would be motivation in = the future to address it another way. =20 That, or go ahead and also propose a `__load` method as part of this = RFC. > On Jun 20, 2024, at 4:57 AM, Lynn wrote: >=20 > Seeing an extra keyword made me think of: > ```php > class Foo > { > public constructor __construct() {} > public destructor __destruct() {} > public static constructor __construct() {} > public static destructor __destruct() {} // probably doesn't make = sense right now > } > ```=20 > This syntax would allow named constructors in the future, or even = omitting the default name. > ```php > class Foo > { > public constructor() {} > public destructor() {} >=20 > public constructor create(int $id) > { > $this->id =3D $id; // no need to call the default __construct, = nor needs to return > } > } > ``` > Not sure if this is even a desired path to take, just wanted to throw = the idea out there. I do like the constructor/destructor vs. function naming, but as I wrote = above I think "__init" =E2=80=94 and for your approach Lynn: = "initializer" =E2=80=94 would be more applicable for static classes = methods, with or without an explicit prefixed static keyword.=20 #fwiw -Mike= --Apple-Mail=_C72E3E3F-4D5B-4FD3-BC79-BE7372E90616 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = Jun 20, 2024, at 9:01 AM, Erick de Azevedo Lima <ericklima.comp@gmail.com> wrot
Mike again:

> Consider that some uses for a static = function need to always occur=20 no matter
> whether or not any other method of = the class is called. My=20 previous email [1] covered several.
> Here [2] is a discussion on StackOverflow of "hooks" = that should be eagerly loaded.
Yes, I = considered this approach before. But then I realized that for covering = the properties initialization,
this = already existing lazy loading mechanism would suffice. At the end of the = RFC,
I consider future scope to create an = early-init. In my opinion, as it covers a more general use for this = init,
it should be implemented maybe using another = magic method, like "__load" or "__link",
which = would be hooks on class loading process and not specific to static = variables initialization

Well, that sure is depressing to hear. =  

Looking back on all my uses = for static methods, my primary use-case when building WordPress websites = was to wire up hooks thus what excited me most about the prospect of = getting "static constructors" in PHP was for wiring up said = hooks.

I get the lack of desire to = support a lazy keyword, especially giving the lazy loading thread = happening on the list, and I agree that lazy loading is better for the = use-cases that motivated you, but it is depressing because the = likelihood of someone else after so many years would have the passion = and motivation to propose a `__load` method AND to have the skills to = implement it is slim-to-none IMO.

So = IOW, a `__load` method it's almost certainly never going to happen. Such = is life I guess.

Well at least let = me submit a parting bikeshed on the name. Rather than any form of = "construct" can you at least name it `__init` or `__initialize`? =  It is not construction, and even in your comment where you wrote = unprompted "...not specific to static variables initialization" you = christened it to be "initialization."

P.S. I do think lazy-loading without an explicit = keyword will be counter-intuitive to many, and will result in many a = StackOverflow question asking "Why are my `__staticConstruct` (or = `__init` as proposed) methods not being called?!?"  So if it were = me I would implement them w/o default lazy loading so there would be = motivation in the future to address it another way.  

That, or go ahead and also propose a `__load` = method as part of this RFC.

On = Jun 20, 2024, at 4:57 AM, Lynn <kjarli@gmail.com> wrote:

Seeing an extra keyword made me think = of:
```php
class Foo
{
  =   public constructor __construct() {}
  =   public destructor __destruct() {}
  =   public static constructor __construct() {}
    public static destructor __destruct() {} // = probably doesn't make sense right now
}
``` 
This syntax would allow named = constructors in the future, or even omitting the default name.
```php
class Foo
{
    public constructor() = {}
    public destructor() {}

    public = constructor create(int $id)
    = {
        $this->id =3D $id; = // no need to call the default __construct, nor needs to = return
    }
}
```
Not sure if this is even a = desired path to take, just wanted to throw the idea out = there.

I do like the constructor/destructor = vs. function naming, but as I wrote above I think "__init" =E2=80=94 = and for your approach Lynn: "initializer" =E2=80=94 would be more = applicable for static classes methods, with or without an explicit = prefixed static keyword. 

#fwiw

-Mike
= --Apple-Mail=_C72E3E3F-4D5B-4FD3-BC79-BE7372E90616--