Hi Rowan,
On Wed, Mar 4, 2015 at 7:12 AM, Rowan Collins <rowan.coll...@gmail.com>
wrote:
> You are measuring the wrong cost. The cost of adding new names is to
> people writing code:
>
> - additional confusion for new users about why everything has two names
> and which they should use
> - extra effort for new developers to learn the new names, even if they
> only read them in other people's code (it slows me down every time I see
> sizeof() and have to remember it's just an alias of count())
> - awkward decision for project leaders: use the old names for familiarity
> and compatibility with older versions, or the new ones because they're
> arguably better names
> - if an existing project does choose the new names, the overhead of
> converting all the existing code, with the risk of bugs introduced by
> incorrect automation, noise in commit logs, merge conflicts, etc
> - if a project needs to run on PHP 5, the vigilance required to avoid
> accidentally using the new names when developing on PHP 7
>
> That's not an exhaustive list, and some of these aren't huge costs, but
> collectively they outweigh the benefit of a slightly more consistent set of
> names for things.
>
> This is why a more radical change - an OO-style API for scalars and basic
> modules, a fundamentally new set of functions which fulfil a specific need,
> etc - has the potential for acceptance, and this proposal does not. The
> costs are mostly fixed, so we need to increase the benefits to outweigh
> them.
>
This is fair discussions. We should care these also. I agree these costs
exist
and shouldn't ignored.
I have different point of views. It's long term view or new user point of
view.
For me, it outweighs costs you've mentioned.
Whether we like it or not, people evaluate languages by matrix like
PHP Ruby Python
OO support 5 5 5
Flexible syntax 3 5 5
AOP support 3 3 3
DbC 1 2 2
API consistency 1 3 3
API richness 4 4 4
3rd Party Libs 4 4 4
Performance 4 3 3
Security 1 4 4
Type Safety 1 4 3
Although this is rough evaluation by me, people would have somewhat similar
matrix.
API consistency 1 3 3
The reasons why people evaluate PHP like this are
- PHP has API inconsistency even for most basic APIs like phpversion(),
htmlspecialchars(), etc
- Even bundled modules have non standard function names.
- API parameter ordering is inconsistent.
- Return type for errors are inconsistent. e.g. Wrong number of param
returns NULL, while others return FALSE mostly.
- Some basic internal classes do not raise exception for instantiation
failure.
- and so on.
I'm not saying Ruby's APIs are organized very well. For example, user has
to search
around proper API even for URI escape provided by various modules.
Therefore, I
evaluate it as 3.
Having this kind of evaluation matrix is not good for PHP in the long run.
IMHO.
BTW,
Security 1 4 4
I evaluate like this because PHP is to weak against fatal security breach.
i.e. Script Inclusions.
You'll see my view and the reason why I focus in some area strongly from
the matrix. Although
I didn't participate scalar type hint RFC discussion much, I cannot wait to
have StrictSTH also.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
