2012/8/21 Andrew Faulds <a...@ajf.me> > On 21/08/12 21:44, Lars Schultz wrote: > >> Am 20.08.2012 22:51, schrieb Andrew Faulds: >> >>> On 20/08/12 21:43, Lars Schultz wrote: >>> 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) >>> >> >> I don't think it's ridiculous because every core functionality to be >> implemented and maintained causes some php-dev to invest time on something, >> which is not absolutely necessary because it could be done, with some >> additional work, in userland. There is a lot of functionality, that can not >> be reasonably well implemented in userland, and php-dev time should be used >> on such cases, no? >> >> With my suggestion, any php-user could suggest a functionality he feels >> is missing to go not into core but into the documentation, with a >> suggestion of how to solve the problem. Therefore the bar, which decides >> wether something is worthy of going into core could stay as high as it is, >> but it could be lower for something that goes into the documentation as an >> example. >> >> The problem is that these functions often improve the readability and > concise expressive power of PHP. Yes, you can import large libraries of > functions, but it is much more programmer-friendly not to. >
Really? Use composer and you'll not feel any difference. Don't use composer and it will require a single 'include' from you. That is "much more user-unfriendly"? At the end in both cases you will not feel any difference. So where is this "readability and concise expressive power", that is no possible with already existing userland tools? > > Also, functions can often improve the *maintainability* of code, as well. > For instance, compare: > > if (startswith($line, "<title>") && endswith($line, "</title>") { > > with: > > if (susbstr($line, 0, 7) === "<title>" && substr($line, -8) === > "</title>") { > > The first is more readable, and more maintainable, since you're not > dealing with manually specified string lengths, which can easily be wrong. Yes, that are functions I can imagine can go into a php-based standard library. They can even be more efficient than the self-made solution (strncmp() is faster than substr() ;)) and the user of startsWith() and endsWith() doesn't even need to take care. > > 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. >>> >> >> Therein lies the crux of it all...how much is too much or too little. >> Who's to say? It's a matter of personal preference, I believe. That's why >> such features will always trigger those discussions. Because it depends on >> one's programming style...of which there are various, various good ones, >> even if not always compatible. >> > There seems to be a problem in here of "if I don't need it, nobody else > does". Of course the reverse "if I need it, everyone else should have it in > core" is also true, but I think the first point is a problem. > > >> That said, not every possible function has a compelling case for >>> addition, simply because it does something too obscure or is impractical. >>> >> >> Sometimes that is obvious and then the discussion will be short or not >> even starts. But mostly it's not. >> >> It quite often is obvious, I fear: the most vocal may often be the > minority. > > > -- > Andrew Faulds > http://ajf.me/ > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- github.com/KingCrunch