Pierre Joye wrote on 05/03/2015 11:49:
On Thu, Mar 5, 2015 at 3:21 AM, Rowan Collins <rowan.coll...@gmail.com> wrote:
Yasuo Ohgaki wrote on 05/03/2015 09:24:
I would love to have new OO APIs for variables. I also like to write
procedural
code for simple scripts. Therefore, even if we have new OO APIs, I would
like to
improve/maintain procedural functions and make them not legacy functions.
I don't see scalar methods primarily as a way to make PHP more OO (it's just
syntax sugar, at the end of the day), but as an opportunity to bring in a
new API with real advantages.
As Jordi says in the other thread, there are other things you could improve
about the array functions beyond making the argument order match the string
functions. If you were to sit down and design a new set of array functions
(for instance), which were a valuable replacement for the old ones, you
wouldn't also need to add dozens of aliases to the old set, because your new
set could have a consistent and intuitive naming and behaviour convention.
Scalar methods are just one way of designing that new set of functions, but
you could just make a namespace of completely redesigned functions, with
deliberately new names to make it obvious which set was being used. At that
point, having the aliases you're proposing would be actively harmful,
because now users would have to ask (themselves/the manual/Stack Overflow)
"is this the new function, or just the new name for the old function?"
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.
For the record, I largely agree. I am open to the possibility of other
*similarly clean-break* solutions, but have not seen one proposed yet.
The fact that scalar methods would look completely different from legacy
functions, including parameter order (because of $this), gives them a
huge head-start over any other approach I can think of.
If "int", "string", et al acted as real classes, and participated in an
extendable hierarchy of "value types", that would be even more awesome,
but entirely incidental to concerns over consistency.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
