On 20/08/12 21:43, Lars Schultz wrote:
Am 20.08.2012 19:43, schrieb Sebastian Krebs:
What I don't understand is, why should every function goes directly into
the core, if you can achieve exactly the same without core changes?
This comment from Sebastian got me thinking. It's true. Every-someone
has his own views on what is absolutely necessary and should be
available to every-one. Depending on ones coding style, it probably is
absolutely necessary.
Whenever a userland implementation is viable, it becomes a strong
argument against embedding it within the core.
It's a ridiculous argument, IMO. Nothing you could add to core couldn't
be implemented in userland code somehow. (yes, that's hyperbole, but
there is very often a userland solution. Most functions are for convenience)
Adding functions is important for convenience as well as functionality.
Sure, it would be nice to have a small set of functions, but those lead
to overly verbose code and waste the time of developers. Yes, many of
them can be easily implemented in userland, but consider this: what if
half (say) of the array or string functions didn't exist and you had to
manually implement each? A little code can quickly become a lot to do a
lot of simple things.
That said, not every possible function has a compelling case for
addition, simply because it does something too obscure or is impractical.
But those suggestions keep coming up and some create more than a
little controversy among the contributors to the list and even among
the core-developers. That said:
Why dont we embed a library of userland code right there in the
documentation, next to the core code, where a php-user would expect or
look for the functionality. They'd have to be properly highlighted as
userland implementations of course but would still be there to be
found in the documentation. This would at least solve the problem of:
- "horrible" implementations, replaced by neatly formed official
userland solutions.
- performance (because they would be as efficient as possible)
- correctness (because discussed on the internals (or docs) list,
almost as if it'd go into the core)
- skill (because everyone can provide a solution, even if he's not
able to write c-code)
- availability (because with a simple copy/paste-action I can use the
provided (currently) official solution immediately.
It sounds a lot like PEAR, I guess...but I wouldn't consider PEAR a
source for a userland implementation of, say, array_remove or
print_r_html. Also its alot more accessible and available than PECL,
because it is after all just PHP code.
I am not sure wether this is a good idea, but it struck me as a better
solution than just saying: it's so simple, do it yourself.
--
Andrew Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
