On Fri, 1 May 2020 at 16:45, Max D <m...@bukrek.net> wrote:
> Greetings, Internals!
>
> This is my first try to input the proposal, please don't be strict )
>
> All the years with PHP I hate writing classes. The need to prefix EVERY
> property and method use looks horrible and writes horrible. So, the
> proposal:
>
> Lets introduce directive
> declare(simple_classes=1);
>
> This directive will switch interpreter mode, where class declared
> properties and methods are accessible as regular variables and functions at
> class code.
>
> So, such a fragment
>
> public function __construct() {
> $this->get = $this->clean($_GET);
> $this->post = $this->clean($_POST);
> $this->request = $this->clean($_REQUEST);
> $this->cookie = $this->clean($_COOKIE);
> $this->files = $this->clean($_FILES);
> $this->server = $this->clean($_SERVER);
> }
>
> will look so with the proposed directive:
>
> public function __construct() {
> $get = clean($_GET);
> $post = clean($_POST);
> $request = clean($_REQUEST);
> $cookie = clean($_COOKIE);
> $files = clean($_FILES);
> $server = clean($_SERVER);
> }
>
> What do we lose with such an approach? The ability to use local variables
> named as class properties and the ability to call regular functions, called
> as class methods. Both things are super-rarely used and programmers have
> the ability to change naming to achieve them.
>
> For static properties/methods, dynamic ones will have an advantage if
> naming matches.
> Of course, the ability to use usual prefixes will be preserved.
>
> I'm not going to implement this, hoping someone will volunteer if the
> reaction is positive.
> Also I have some more proposals I will post if this one goes nice.
>
> With best regards,
> MaxD
>
This clashes with local scope variable definition, that's one and as others
mentioned - it plain simple probably is not possible to implement unless
you make a special exclusion for __construct and that's a horrible horrible
idea (just look at the history of PHP how making special handling of things
turned out).
Second - code readability. You write code once, you may modify it once in a
blue moon (it being a constructor makes it far less touched). But you and
your colleagues, including future developers, read that code constantly and
it will be just plain confusing to read that code. $this-> makes it
explicit you work with the class properties and it's a good thing.
Third - these days, if people are bothered with writing repeating code,
there are a lot of tooling that makes it super easy - from code generation
to code completion in various editors and IDE's (PhpStorm being my personal
preference - all I need to do is write constructor arguments - IDE will
generate class properties and assign them in the constructor in 2
keystrokes). Refusing to use the tools is a personal preference of each
individual, but that also means those individuals can't start to request
all the syntax sugar they can just to make their life easier a little bit
at the expense of things like code readability or other people having to
learn a crapload of syntax sugar and deal with it.
On a personal note: If you want a lot of syntax sugar and fancy stuff -
there is Ruby and Python and other languages for that, that are doing it
better and are designed with all that in mind. PHP is a different type of
language, it's expressive and for the most part a straight forward one and
that makes development in it somewhat easy even with the bigger stuff. It
also makes junior devs pick it up easily and not make as many mistakes
because it is explicit and there is not much magic behind (well, unless you
use magic methods, but at least in my development environment we completely
don't use them at all - everything is explicitly defined).
There is a line where you have to think about the fact that maybe it's time
to switch languages because you want different things and the language you
are using is not suited for that any more. The right tool for the job
principle. For example, I tried myself some Ruby and I don't like it as a
language and I'm sticking to PHP for web development as my tool exactly
because of syntax it has, limited amounts of magic and with 7 series it
having tons of improvements on the error and variable handling that allow
me to write stricter code + all the tooling in the ecosystem.
Some improvements to the language are nice, there for sure have been some
good once. But it needs to fit the PHP and this proposal is pure and simple
"out there" and, clearly, has not even been considered if it's technically
feasible, and as far as I know, the PHP AST parser just can't handle this
ambiguous case (and it will be a bad special case).
--
Arvīds Godjuks
+371 26 851 664
arvids.godj...@gmail.com
Skype: psihius
Telegram: @psihius https://t.me/psihius
