On Tue, Oct 1, 2024, at 2:06 PM, Rowan Tommins [IMSoP] wrote:
> On Tue, 1 Oct 2024, at 19:29, Larry Garfield wrote:
>> I would have said with() would be neat in PHP. :-)
>
> I have been considering for a while proposing Context Managers
> [Python's with(), not to be confused with VisualBasic & Jav
On Tue, 1 Oct 2024, at 19:29, Larry Garfield wrote:
> I would have said with() would be neat in PHP. :-)
I have been considering for a while proposing Context Managers [Python's
with(), not to be confused with VisualBasic & JavaScript unrelated feature with
the same keyword].
My primary example
On Tue, Oct 1, 2024, at 10:39 AM, K Sandvik wrote:
>> On Oct 1, 2024, at 5:12 AM, Arnaud Le Blanc wrote:
>>
>> Some use-cases of destructors could be replaced with patterns like
>> Python's with() [3], Java's try-with [4], or Go's defer [5].
>
> defer would be neat in PHP. --Kent
I would have sa
> On Oct 1, 2024, at 5:12 AM, Arnaud Le Blanc wrote:
>
> Some use-cases of destructors could be replaced with patterns like
> Python's with() [3], Java's try-with [4], or Go's defer [5].
defer would be neat in PHP. --Kent
Hi Jonathan,
> It seems the protected but not private destructors idea was already
> implemented for PHP 7 (https://3v4l.org/6DFGp) but fell victim to a
> regression in 7.3.15/7.4.3 and no-one noticed because it was never added
> to the changelog in the first place.
Apparently the engine can succ
Hi Christoph,
On Sat, Sep 28, 2024 at 4:47 PM Christoph M. Becker wrote:
> > Besides closing resources and killing processes I've seen them store
> > data to disk for caching, remove temp files, call callbacks/dispatch
> > events, change state on other objects, dump stored errors to error_log
> >
On Sep 28, 2024, at 13:23, Jonathan Vollebregt wrote:
>
>> Okay. My point is that you cannot know (unless there are no circular
>> dependencies) *when* a destructor is called by the engine;
>
> The benefit of non-public visibility isn't when it's called, but how many
> times it's called. If yo
Okay. My point is that you cannot know (unless there are no circular
dependencies) *when* a destructor is called by the engine;
The benefit of non-public visibility isn't when it's called, but how
many times it's called. If you can declare your destructor non-public
you can be confident it'll
On Sat, Sep 28, 2024, at 16:46, Christoph M. Becker wrote:
> On 28.09.2024 at 16:21, Jonathan Vollebregt wrote:
>
> >> Hmm, I wonder about the use-cases of userland destructors. It seems to
> >> me they are mostly useful for sanity checks, and maybe to close
> >> resources. Are there others?
> >
On 28.09.2024 at 16:21, Jonathan Vollebregt wrote:
>> Hmm, I wonder about the use-cases of userland destructors. It seems to
>> me they are mostly useful for sanity checks, and maybe to close
>> resources. Are there others?
>>
>> If not, I wouldn't worry much about the visibility of destructors,
Hmm, I wonder about the use-cases of userland destructors. It seems to
me they are mostly useful for sanity checks, and maybe to close
resources. Are there others?
If not, I wouldn't worry much about the visibility of destructors,
because resources are scheduled for replacement anyway.
Beside
On 27.09.2024 at 14:32, Jonathan Vollebregt wrote:
> Long story short I'd like to suggest:
>
> 1. Allow the engine to call protected destructors (again)
> 2. Warning when declaring a private destructor as with other magic methods
> 3. Documentation update to confirm private destructors aren't allo
Hello all,
On github I reported a bug causing errors when objects go out of scope
with a protected/private destructor:
https://github.com/php/php-src/issues/16077
Example code: https://3v4l.org/bKijA
The magic methods documentation says:
All magic methods, with the exception of __construct
13 matches
Mail list logo
