In 1985, my parents went to West Germany with an organized tour and smuggled a ZX Spectrum for us. At the same time, they sent me to a computer - focused daycamp at a community center. Yes, of course, we played games, I was ten but I learned ZX Spectrum BASIC, too.
Jump forward twenty years and I got my first Western programming job for the then-unimaginable 5000 USD a month. This company also happened to be headquartered in Vancouver where I decided to immigrate to and they helped me doing so. And when this company got acquired four years later, I got a salary high enough to buy my own apartment on the beautiful seashore of Vancouver.
My father went to West Germany on a business trip with instructions to purchase Spectrum. Sadly, he returned with Atari 800 XL. I say sadly because any software was very hard to find in ex Yugoslavia while stuff for Spectrum was widely spread (all pirated, of course), even transmitted on FM radio.
Although I didn't move to Canada, it lead to the similar outcome of a good IT career. In essence, cheap home computers opened our eyes as to what oportunities exist, and that we are not bounded by borders where we were born in. I'm sure there are many success stories from East Europe which started with Spectrum, C64, or even Atari 800XL.
In my case, I started with the ZX-81 and never emigrated, but I can relate to everything else. Thanks to Sir Clive, I have a great career and lots of fun with hobbies that are mostly related to computers. 10/10 would do it again!
Not only that but if you have a multiple continental team then no one needs to be waken by an emergency meow. (My PagerDuty is set to a meow sound. So we practice meow driven development: I don't want to hear my phone meowing piteously.) Say, you have someone on the US west coast they can do 10am-10pm while someone else in continental Europe being nine hours ahead can do 7am-7pm.
That would be some really old library. Already in 2012 when Composer was released there was PSR-0 and today almost all libraries are Composer managed and using a namespace following PSR-4 which itself is ten years old. A library that old would almost surely not run on PHP 8 unchanged anyways.
Surrendering the global namespace to the language is not so bad an idea.
Suppose I want to add some new code to an old website? Or I want to gradually upgrade an ancient code base - twelve years is not so old for PHP, when ancient frameworks like Wordpress are still alive and kicking.
If we hitched language development on Wordpress we would still be on PHP4 as they refused to join gophp5 some seventeen years ago.
Again, an ancient enough codebase which contains a library using array_find will need enough upgrades to run on PHP8 much less PHP8.4 the change from array_find to something else is the least of your worries.
Seriously? 2k results for array_find in PHP on GitHub: https://github.com/search?q=array_find++language%3APHP&type=.... RFC authors (https://wiki.php.net/rfc/array_find) explicitly noted over 600 hits for definitions of array_find, around 30% of which are not false positives - that is, there's a good possibility that there are 200+ implementations of global array_find in just open-source projects.
There are so many more examples. Lots of the hits are from codebases that have seen updates in the last few years. Many more are plugins or other addons for PHP frameworks or apps which are still widely used (WordPress, phpBB, etc.).
IIUC the `use` declaration is including the target namespace (https://laravel.com/api/8.x/Illuminate/Support/Arr.html) in the current scope, not declaring a namespace itself. If you wanted to create a namespace you need the `namespace` declaration, which this file lacks. `helpers.php` is directly included by both `index.php` and `artisan` and the functions are thereby in the global scope of the entire app.
In any case, it wouldn't make sense for that file to be namespaced under Illuminate\Support\Arr, as most of those functions have nothing to do with arrays.
Anyway, it _could_ have been namespaced. It _should_ have been namespaced. I'm sad for the app author, but he should have seen that coming. His app was developed well after namespaces were introduced.
You're making impossible demands. PHP has chosen to be backwards compatible _to a certain point in the past_, and it is generous in what it decides to keep working.
To expect that 8.4 will care about not breaking some code that was written with 5.2 style is unrealistic.
You're making a time travel judgement. You're saying that PHP should have renamed everything back then to categorized namespaces and broken compatibility _way_ earlier, which is actually a much worse break than the break that actually happened.
8.4 is not even backwards compatible with perfectly working code written to target 8.x. It doesn't materially matter that the code is written in "5.2" style if it was meant to run on only 8.x. Even that style point is arguable. The author uses Composer! And Laravel! And mostly does use namespaces, outside of a few useful helper functions that are reasonably global so they don't keep needing to import them or use namespace prefixes.
> Property hooks mean that some language magic will turn a property access into a call to methods.
__get / __set was doing that already and some frameworks very heavily rely on those.
> It implies that `$this->x` has a different meaning if it's inside a hook or outside hooks.
this is a valid critique but hopefully hooks will be super short and this won't be a major issue. Indeed, if your get is not an arrow function -- which only allows one statement -- then it needs a good thinking over whether this is indeed the best solution. Ie if your get is so complicated then perhaps a helper method is best and then you have get => $this->foo($this->thing) and that's the only place where $this->thing is special.
> hopefully hooks will be super short and this won't be a major issue.
Even if a PHP project has a policy of short hooks, I think hooks impede clarity.
public string $countryCode
{
set (string $countryCode) {
$this->countryCode = strtoupper($countryCode);
$this->country = nameCountry($this->countryCode);
}
get => ...
In this short hook, the first line of the setter obviously uses the underlying property. But the second line of the setter...
Does `$this->country =` use the setter even if it's in a hook (but not a `country` hook)?
Does reading `$this->countryCode` use the getter hook, even it's from a `countryCode` hook?
If not, is there a way to call the `countryCode` getter from this setter?
If quickly parsed the doc and the RFC, so I don't have answers (I suppose it's yes, no, no). But even if I knew how this code behaved, I would still think it's much more complex than plain methods.
> Does `$this->country =` use the setter even if it's in a hook (but not a `country` hook)?
To me it is obvious hooks won't use other hooks because that could lead to an infinite loop in a hurry
> Does reading `$this->countryCode` use the getter hook, even it's from a `countryCode` hook?
same
> If not, is there a way to call the `countryCode` getter from this setter?
There is although it's a bit tricky and not intuitive but I feel this falls under the "it is enough this is possible, there's no need for it to be easy": "Be aware, the detection logic works on $this->[propertyName] directly at compile time, not on dynamic forms of it like $prop = 'beep'; $this->$prop. That will not trigger a backing value." Using dynamic properties in what should be simple code should be rare enough this is not a problem. It's like a bridge convention, the benefits vastly outweigh the drawbacks.
> Does `$this->country =` use the setter even if it's in a hook (but not a `country` hook)?
To me it is obvious hooks won't use other hooks because that could lead to an infinite loop in a hurry
I would expect hooks for properties other than `$this->contryCode` to be called inside of a `$this->contryCode` hook.
Btw the docs that are linked in the post[0] seem to be clearer than the example in the announcement. Reads less ambiguously to me.
> if there is any possible way to do that without "boots on the ground"
Of course there is but the Western allies are slow to arm Ukraine because they fear the Russian nuclear retaliation.
To recap, Ukraine received very few , around a hundred ATACMS missiles with severe restrictions on targets. They got less than two dozen F-16 jets. This is just nothing compared what the US might be able to send if they wanted to, they have over 300 Falcons at Davis-Monthan AFB (aka Boneyard) to begin with. There are near four thousand ATACMS missiles manufactured so far. And so on, with tanks etc.
If the "tap" were to open full stream instead of dripping, the war would be over very fast. The question is, which end would we get.
If you only listen to think tanks and professors that affirm your preconceptions then you're not educating yourself at all. Liberals fall into the same trap of denying genocides when they demand that Noam Chomsky's memoirs be the only relevant framing of geopolitics. It's a nonsense diversion, and you even added a scoop of ad-hominem on top.
With credit to the parent comment, I've seen the linked video and it's both high quality and entertaining. I'd also wager it's more peer-reviewed than whatever primary sources you use, if you think NATO is the villain for offering the protection Russia's neighbors want.
Jump forward twenty years and I got my first Western programming job for the then-unimaginable 5000 USD a month. This company also happened to be headquartered in Vancouver where I decided to immigrate to and they helped me doing so. And when this company got acquired four years later, I got a salary high enough to buy my own apartment on the beautiful seashore of Vancouver.
Thanks Speccy for what my life could become.