Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109963
MIME-Version: 1.0
References: <CAPNm5sMWF=XOe-H_erfSm0jPerAxKGnXENetbbH+BUZDi+yiiw@mail.gmail.com>
 <CAL0xaBGQZRD4EaB8223VZsEYd_TFqOgHKofgncTuezmu3Wc1-g@mail.gmail.com>
In-Reply-To: <CAL0xaBGQZRD4EaB8223VZsEYd_TFqOgHKofgncTuezmu3Wc1-g@mail.gmail.com>
Date: Sat, 2 May 2020 15:36:25 +0300
Message-ID: <CAPNm5sNM7qi0fC4bXW_fYusPSj7SvZDc6hTS=wEEP2A51MkM5w@mail.gmail.com>
To: Arvids Godjuks <arvids.godjuks@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000087da2c05a4a98ce7"
Subject: Re: [PHP-DEV] Simplify classes syntax proposal
From: max@bukrek.net (Max D)

--00000000000087da2c05a4a98ce7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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


=D0=BF=D1=82, 1 =D1=82=D1=80=D0=B0=D0=B2. 2020 =D0=BE 20:11 Arvids Godjuks =
<arvids.godjuks@gmail.com> =D0=BF=D0=B8=D1=88=D0=B5:

>
>
> On Fri, 1 May 2020 at 16:45, Max D <max@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=3D1);
>>
>> 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 =3D $this->clean($_GET);
>>    $this->post =3D $this->clean($_POST);
>>    $this->request =3D $this->clean($_REQUEST);
>>    $this->cookie =3D $this->clean($_COOKIE);
>>    $this->files =3D $this->clean($_FILES);
>>    $this->server =3D $this->clean($_SERVER);
>> }
>>
>> will look so with the proposed directive:
>>
>> public function __construct() {
>>    $get =3D clean($_GET);
>>    $post =3D clean($_POST);
>>    $request =3D clean($_REQUEST);
>>    $cookie =3D clean($_COOKIE);
>>    $files =3D clean($_FILES);
>>    $server =3D clean($_SERVER);
>> }
>>
>> What do we lose with such an approach? The ability to use local variable=
s
>> 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 handlin=
g
> 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 a=
nd
> your colleagues, including future developers, read that code constantly a=
nd
> 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 generatio=
n
> to code completion in various editors and IDE's (PhpStorm being my person=
al
> 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 an=
d
> 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 y=
ou
> use magic methods, but at least in my development environment we complete=
ly
> 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 langua=
ge
> 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 simp=
le
> "out there" and, clearly, has not even been considered if it's technicall=
y
> 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=C4=ABds Godjuks
>
> +371 26 851 664
> arvids.godjuks@gmail.com
> Skype: psihius
> Telegram: @psihius https://t.me/psihius
>

--00000000000087da2c05a4a98ce7--