Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91379
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fleshgrinder.com from 212.232.28.122 cause and error)
Reply-To: internals@lists.php.net
References: <56C77575.4090906@fleshgrinder.com> <56C77FC8.1070500@gmail.com>
 <56C78496.9020804@fleshgrinder.com> <56CB6BA7.8060500@gmail.com>
To: internals@lists.php.net
Message-ID: <56CDEB49.5040006@fleshgrinder.com>
Date: Wed, 24 Feb 2016 18:41:29 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <56CB6BA7.8060500@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="XfVIWX322iQPilRanaQenbr3M6HPDf5rb"
Subject: Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal
From: php@fleshgrinder.com (Fleshgrinder)

--XfVIWX322iQPilRanaQenbr3M6HPDf5rb
Content-Type: multipart/mixed; boundary="TLI6sO4alhpTQUbgJqtNtIB40jXJ8bkC8"
From: Fleshgrinder <php@fleshgrinder.com>
Reply-To: internals@lists.php.net
To: internals@lists.php.net
Message-ID: <56CDEB49.5040006@fleshgrinder.com>
Subject: Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal
References: <56C77575.4090906@fleshgrinder.com> <56C77FC8.1070500@gmail.com>
 <56C78496.9020804@fleshgrinder.com> <56CB6BA7.8060500@gmail.com>
In-Reply-To: <56CB6BA7.8060500@gmail.com>

--TLI6sO4alhpTQUbgJqtNtIB40jXJ8bkC8
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 2/22/2016 9:12 PM, Stanislav Malyshev wrote:
> Hi!

Hey there. :)

On 2/22/2016 9:12 PM, Stanislav Malyshev wrote:
>> Old cellphones were shipped with a user manual that contained precise
>> instructions on how to deal with the installed OS.
>=20
> You don't really need a whole manual to know two things are the same.
> You only need one line from that manual. It's a minimal effort, well
> within expected of what may be required of a person learning new
> language - I think reading a couple of lines is not excessive.
>=20
>> New smartphones do not contain a user manual because the OS is so
>> intuitive that nobody has a need for them.
>=20
> Or so the marketing team would love us to believe ;)
> If you think a programming language somehow can be so "intuitive" that
> you never need to actually know anything to use it - you're in for a
> somewhat unpleasant surprise, unfortunately. We can make learning it
> easi-er - and having aliases is part of it - but we can never make it s=
o
> easy as never having to actually touch the manual or any other learning=

> media.

My example seems to be bad or to abstract. I am not thinking that a
programming language can become that intuitive; the contrary.
Programming languages are already so complicated that it is harmful to
start littering them with thousands of ways to achieve one thing. It
also makes users uncertain when the manual entry says that something is
an alias. They fear that it might be removed. They create project rules
that forbid the usage of aliases ...

Science shows that it is harmful, let's clean it up!

>> discussion because you simply say no and do not even allow a
>=20
> That is not correct. I say no with substantiation - namely, that
> removing aliases would cause code breakage and would not add anything t=
o
> actual functionality. Your argument seems to be generic "redundancy is
> bad" argument, and treating somebody asking questions on stackoverflow
> as evidence that we have a problem. Both are wrong - redudancy can be
> both good and bad, and in our case I think it is good because it lets
> people continue to rely on their previous experience both in PHP and
> other languages. Also, somebody asking questions is not a reason to
> change the language - there always will be people asking questions, and=

> that's fine as long as we have good easily accessible answers, which we=
 do.

In Germany we say "jain" (yes and no). You are right that you brought up
that argument and I acknowledged it but put it like you did not bring up
one in my last message. I am sorry for that. You are not right that
Stackoverflow is my only argument. I provided scientific proof that
those aliases harm the design of a language and a more general proof in
regards to usability and duplication.

People often rely on side effects but that does not mean that this is a
good practice. We are talking here about a feature that was added in PHP
4 in order to support OO coding. The feature is not used anymore by a
major part of the community and it is considered best practice to use
the proper access modifiers (namely public in this case). We are talking
about a future version of PHP (probably 8) and not about removing it
from PHP 4, 5, nor 7.

There is only one constant in life and that is change. Insisting on not
changing means to stop; especially in a context of software development
and engineering (which actually implies constant change in its own name).=


--=20
Richard "Fleshgrinder" Fussenegger


--TLI6sO4alhpTQUbgJqtNtIB40jXJ8bkC8--

--XfVIWX322iQPilRanaQenbr3M6HPDf5rb
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWzetOAAoJEOKkKcqFPVVrACcP/A+7IJW61HYFZALtft6BxmZP
5Zeri6CdoMJ6UApKCSehB9m6vq4/7/Buhq2IFmBDMhz8a5mRkz9I+bsBUpAzI2KJ
Kf+RxeiiKHi6VKJl03mX+EJqbrZlF32eHQXiWyy1MHGr90TUYj9ZiY5ZF07gSflu
X4IWqA/tBdSAzSdvYfaaVg5xhYFDPnC+TAHQCFRbxYQom+rfixAg0MwPW7o87SR1
q2GQnxNd3rdsi88uFd9kYBmQAOxizd7nRmskicU6P2xto1Jpx1dKemFR+Uj3PkpL
Qj4xo7HAXc7zAj/frRH7W6RojRF4UzQGc9jqEw0H3tF1UVmT6TItGq/P4KFVYzd8
Ui5M5cuZY48furtMHikqPQ4hiciILRqZevaJqiYlK2rdfuUlf0GDXZb3Ok2/NME0
sarsPFwuPf1To1YdyloH91lmvc5U0bJ5+NWor4XqpL3c5+us7A0GvKd7ipdfWvzF
lLI/DfLvttg3Ic+bp1vg9Fx2hmG6rQRkDPdUGKb8NMZ3aUwt+P5/TeIOvi1Ct4ZQ
2a4xcwlih+x4EI6dlExz8Pt+sex2aGEaPj9H3oFMwwD+Lh4ijkyUoPOkHsAP+Lcp
OOQ8MU43aa6YWkvbs7n0Hsf4hPYTsOPss6YEULH7x8od8UBRmyPLE/LIQBOLXBjv
78V2RaUcncokDBgtrzwi
=mkqi
-----END PGP SIGNATURE-----

--XfVIWX322iQPilRanaQenbr3M6HPDf5rb--