Thank you guys for all your feedback!
It's a big surprise for me that so many people love PHP for this style of
referring.
Sure, I am out of the pack. I am stuck to PHP due to my activity type and
mostly write a lot of code no one reads except me.
I have found my own way to deal with it. Mostly PHP classes are used once
per session, so I mimic the desired approach by using regular procedures +
global variables.
Sure, that is not good style, but that's the only choice I have.
Anyway, long live PHP ;-)
With best regards,
MaxD
пт, 1 трав. 2020 о 20:11 Arvids Godjuks <arvids.godj...@gmail.com> пише:
>
>
> 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
>
