Yasuo Ohgaki wrote on 05/03/2015 20:20:
Hi Arvids,
On Thu, Mar 5, 2015 at 9:32 PM, Arvids Godjuks
<arvids.godj...@gmail.com <mailto:arvids.godj...@gmail.com>> wrote:
2015-03-05 13:49 GMT+02:00 Pierre Joye <pierre....@gmail.com
<mailto:pierre....@gmail.com>>:
>
>
> I will say it again a last time, in my opinion only a clean API;
> object-like or real object as long as performance is not affected is
> the only way I could see to actually solve this problem.
>
> Changing the names, argument order (pointless once we will have
named
> arguments, btw) and similar solutions are band aids solutions,
> confusing at best, terrible at worst. It is pointless to do it after
> almost two decades for some of them.
>
> --
> Pierre
>
> I'm with Pierre here.
Adding aliases is gonna mess up things even more. For example -
autocomplete will become hard to navigate. It's already quite
lengthy list
a lot of the times and it's easier just to write the whole
function name
sometimes by hand. Adding aliases will make it worse.
I agree. Therefore, I'm going to update manual also so that it recommends
main function, not aliases. Aliases should be alternative.
Manual and IDE don't have to list all of them. New manual lists only main
functions, does not have dedicated pages for aliases but aliases are
mentioned
in main function page as aliases.
You can't fix everyone's IDEs for them. You can't fix all the
documentation (tutorials, blogs, Q&As) not hosted on php.net. Most of
all, you can't fix the thousands of projects already written in PHP
using the "wrong" function names, most of which will want to *continue*
using those function names, because that will be internally consistent,
and portable between versions.
The problems people are pointing out are not ones that you can promise
to fix.
We really need a new API, that is not crossing paths with the old.
That way
people can start building stuff on new API's and we could phase
out the old
mess, for example: depricate in PHP8, remove in PHP9.
Stop-gap measures have created enough problems already, or did
everyone
suddenly got an amnesia and forgot all the past lessons on the list?
PHP should be multi paradigm language, not pure OO language.
IMO. Python does good job.
The paragraph you are replying to says "new API". It does not say "pure
OO". As I've said before, the relevance of scalar methods is not that
objects are cool and functions are boring; it's that they're something
new we can design from scratch without worrying about the 20 years of
legacy the existing API has.
I finally understand why some of us against this change and suggest OO
APIs
as alternative. It's reasonable making procedural APIs a
legacy/unmaintained/
messed up to discard procedural APIs someday. I'm against it. PHP should
be like Python in this regard. IMO.
OK, so let's look at our options to maintain the language as multi-paradigm:
1) Implement piecemeal tweaks to the current API, adding to the
confusion of users, in the hope that eventually we accumulate enough
fixes, everyone gets used to them, the old ones die away somehow, and
the result is a slightly nicer set of functions, with various awkward
compromises along the way.
2) Find a way of designing a clean-break new API which is still
procedural. More than just a namespace, which is basically just some new
names with \ in; and definitely not something where the same code can
mean a different thing depending on a setting or import at the top of
the file. Something which will feel fresh, which users will want to
start using, and will recognise when they see code using it.
I don't what that might look like, but if you have some ideas, that is
how you will move this discussion forward, with a radical new solution;
everything you have said so far are things which have been said over and
over again before. Come up with something which nobody has thought of
before, or take our word for it that everyone who has previously
proposed this has failed.
Regards,
--
Rowan Collins
[IMSoP]
