Typed Properties in PHP 7.4

Don't they fall under the cheaper individual license?

Already Chairs, Desk and Rent for every engineer is more expensive than 200 USD every year. Their salary is many hundred times 200 USD. I pay more for coffee and water that they can get for free every year.

Independent devs without income can get PHPStorm at much lower rates.

First, that $200 rate is for teams; independent devs can pay a significantly lower rate (the catch is, you have to pay it personally, not expense it or be reimbursed by an employer).

And even for teams, $200 a year is nothing. If you can afford to hire devs in a first world country (US/EU/Aus/etc), you can afford tools for them. NO employer you should possibly consider working for is going to quibble over the license fee; not when they're already paying 1000 times that in fully loaded costs in salary/rent/overheads/benefits/etc.

If you can't find $200 for a tool to help you do your job, you're not really a professional. (Again, in a 1st world country.)

- The yearly cost is purely for updates. Meaning you could just pay one time, get updates for a year and then continue using whatever version you have. - For small teams they offer a 50% discount (less than 10 people, in business less than 5 years) - If this is perhaps an open source project you can get it for free.

I got sucked into the Jetbrains family because of just how good their PhpStorm is. Especially in regards to refactoring and debugging tools.

I only wish their Javascript tools were anywhere near as good as their Php tools.

Similar to browser docs what you're often interetested in is the latest things and how far back you can use them, and where they will degrade gracefully further back.

Those mostly assume you have old code that you want to make work on new versions, not that you want to write new code that takes advantage of as much new stuff as possible while still working reasonably well on old versions.

It's understandable that they would prefer that everyone just upgrade faster, so it's probably not something they want to encourage (both in documentation and in making features degrade gracefully if that requires any tradeoffs.).

So maybe upgrading PHP itself might not be that bad, something I can't tell you for sure, but in my experience nobody uses vanilla PHP, they all wrap it in frameworks, and those must all be carefully upgraded too.

There are a few edge cases out there of course. Maybe your code base has basically been in stasis since the early days of PHP 5.x, may not even be using composer or namespaces, relies on tons of abandoned or horribly outdated dependencies, doesn't have good test coverage, etc., and then suddenly someone gets a bee in their bonnet about PHP 7.x and wants to upgrade. That's often not going to work out very well, but that's not really a PHP 7.x (or even a PHP thing). :) If you've been maintaining the code, have tests, no ancient vulnerable libraries, using current framework versions, etc, the process is going to be easy. If you're trying a big bang upgrade straight from the medieval period, not so much!

The reason is that i want to know "on site" what exactly is going on when reading and debugging code, especially outside a "smart" IDE, like when diffing changes via the command line, a web-based VCS frontend or some code review tool - especially since these tend to not show the entire code, meaning i need to switch back and forth. But even with an IDE that can show me the inferred types, it is almost always (while i say "almost always" i really mean "always" since i haven't seen any other, but there might be some IDE i haven't tried) done through some popup under the mouse cursor, meaning it is transient and slow.

For similar reasons i dislike features like operator overloading, placing non-self-initializing logic in constructors (and the equivalent in destructors), properties for anything that involves complex calculations (unless the language uses special syntax for properties that make them stand out when used) especially for getters, i prefer to use names that hint to what the code does (e.g. i'd use something like "get_foo" only if it doesn't do any calculations and give you a precomputed or cached "foo", otherwise i'd use an "action" verb like "calc_foo" or "find_foo" or whatever to hint that there is some calculation going on and isn't just a dumb getter), i avoid exceptions as they create hidden exit points for functions (and if the IDE/editor allows, i use a more visible - like bold red - font for "return" or the language equivalent so that explicit exit points are obvious), etc.

Yeah, these make code more verbose and you need to type more, but IMO the negatives are grossly overwhined against and while the positives way too overlooked.

They just ignored the fact that Java is compiled which makes all the layers of abstraction less of an issue whereas PHP is interpreted at runtime* hence why there are few high traffic websites on PHP that don't have at least four layers of caching.

* Yes, I know this is getting better with every version, opcache getting a lot of attention in the last few minor releases and all that, but there is only so much optimization you can do with dozens and dozens of layers of factories and services. My guess is that it does a LOT more for "simple" software like WordPress and less for, say, Symfony based projects.

Example:

    $c = new stdClass;
    $c->test = function() { return 'hello world'; };
    echo ($c->test)();

<?php trait MetaTrait {

    private $methods = array();

    public function addMethod($methodName, $methodCallable)
    {
        if (!is_callable($methodCallable)) {
            throw new InvalidArgumentException('Second param must be callable');
        }
        $this->methods[$methodName] = Closure::bind($methodCallable, $this, get_class());
    }

    public function __call($methodName, array $args)
    {
        if (isset($this->methods[$methodName])) {
            return call_user_func_array($this->methods[$methodName], $args);
        }

        throw RunTimeException('There is no method with the given name to call');
    }

test.php <?php require 'MetaTrait.php';

class HackThursday { use MetaTrait;

    private $dayOfWeek = 'Thursday';

$test = new HackThursday(); $test->addMethod('when', function () { return $this->dayOfWeek; });

echo $test->when();

Seriously I have noticed that static vs dynammic preference is quite sustainable thing for people. Even if you are have used lot of both most people prefer the one they are used when they 'got it' during their programming learning path.

I don't really understand that CSV example what's the problem but one concrete challenge I have noticed with static types is when you want do mutation which effectively change the type. Instead of setting just new property you have to potentially do dummy copy (including type) or some additional hashmap by id for this additional data.

(btw I am not your down voter)