On 11/26/24 9:35 PM, Larry Garfield wrote:
Thinking aloud, my expectation would be that it behaves similarly to how final
static methods would behave. Which appears to be a syntax error:
https://3v4l.org/j8mp0#v8.4.1
So, shouldn't properties do the same?
Without final you can still overrid
On 11/11/24 8:11 PM, Larry Garfield wrote:
Metrics that go into a black box with a 3rd party are bad. That's not what is
being proposed.
From my perspective it's still minified (obfuscated) code going into a
black box. Just because you own the box doesn't make it any more
transparent to me.
On 11/5/24 6:29 PM, Larry Garfield wrote:
Overall I feel like the signal we can get from using a JS tracker
specifically is comparatively low to the point it's not actually worth it.
Some more things a client-side tracker could do that logs cannot:
* How many people are accessing the site from
On 11/2/24 12:10 AM, Bob Weinand wrote:
What percentage of users get to the docs through direct links vs
the home page
That's something you can generally infer from server logs - was the home
page accessed from that IP right before another page was opened? It's
not as accurate, but for a
On 10/30/24 9:31 AM, Alexandru Pătrănescu wrote:
Hi Tim,
So, why not allow capturing, since anyway the only place to capture are
constants and static variables?
And this way we could have short closures with auto-capture.
If there are some technical reasons for not doing that, can we
have wri
I see a lot of the complaints in the lkml thread being about lack of
transparency on gkh/torvalds' side in that they have refused to explain
exactly why they took the action in that commit.
Are we sure this has anything to do with this particular EO?
Rather than speculating on which unnamed sa
On 10/14/24 4:37 AM, Valentin Udaltsov wrote:
First of all, I have already agreed above that PHP does not have a BC
break here. Now we are discussing the potential problems in the PHP
ecosystem and how they could be mitigated.
Then perhaps we should change the name of the thread, since the titl
A "proper" implementation won't break, but there may be subtle ways that
"improper" implementations will break and thus it should be considered a BC break.
This thread is fallaciously equating breaks in third-party libraries
_when changing consumer code_, with breaks just by updating PHP.
If
On 10/9/24 5:01 PM, Valentin Udaltsov wrote:
While not explicitly stated in changelogs, this was a BC break,
because a changed semantic of smth that existed before is a BC break.
Since readonly was only introduced in 8.1 this wasn't a BC break. You
couldn't have a readonly property before so n
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
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
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
12 matches
Mail list logo
