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
