Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62362
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.83.42 as permitted sender)
MIME-Version: 1.0
Sender: sebastian.krebs.berlin@gmail.com
In-Reply-To: <5033F500.9090209@ajf.me>
References: <5032A163.9040500@toolpark.com>
	<5032A35B.4020409@ajf.me>
	<5033F315.7010608@toolpark.com>
	<5033F500.9090209@ajf.me>
Date: Tue, 21 Aug 2012 23:22:20 +0200
Message-ID: <CALtuQzDRzwGFRaa-9NfkpvrrCZR-b8puk=64afhBtUn-Yaxzhg@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary=047d7b343958bd0dfe04c7cd383d
Subject: Re: [PHP-DEV] Official Userland Library (was: removing an item from
 an array)
From: krebs.seb@gmail.com (Sebastian Krebs)

--047d7b343958bd0dfe04c7cd383d
Content-Type: text/plain; charset=ISO-8859-1

2012/8/21 Andrew Faulds <ajf@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

--047d7b343958bd0dfe04c7cd383d--