Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:62357 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 36298 invoked from network); 21 Aug 2012 20:40:13 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 21 Aug 2012 20:40:13 -0000 Authentication-Results: pb1.pair.com smtp.mail=krebs.seb@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=sebastian.krebs.berlin@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.83.42 as permitted sender) X-PHP-List-Original-Sender: krebs.seb@gmail.com X-Host-Fingerprint: 74.125.83.42 mail-ee0-f42.google.com Received: from [74.125.83.42] ([74.125.83.42:35246] helo=mail-ee0-f42.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 8E/65-10139-B22F3305 for ; Tue, 21 Aug 2012 16:40:12 -0400 Received: by eekb15 with SMTP id b15so74924eek.29 for ; Tue, 21 Aug 2012 13:40:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:x-google-sender-delegation:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type; bh=CLhl9Ep880dB6V2ONYVzwnbJBOrWqnujMZrMaPGFGJ8=; b=l6szzmp97EbvBnzl+zETbMTimHBDhFQrMJSodWjnwv5Zbn/JQf9PSTUvexjuLDNNH7 izeVhepmd1mz8JGBYx3y2H6GN9klUafBjfBkczrQHxDz8SW91vn7v2DplkgsHujVhVaT zZA7Prc5VrporkaqGVZmkZRINMNmyILAdD6VNUdOOurgo291CU0r87VUiKxnPkmDbY+2 W9KWwmOKh4kqjSpe8IJ2TEbO8POE0AfIydncDlKr12h2cg5qaBZD2U7jO935C7IH1RcB 33vpZi6EzE4Z2zcmDsxwILAf0mMGcK7vz8x0/0GAwE/CXki5Y6z6kfp3RHA0Ggp5kUn+ cU0A== MIME-Version: 1.0 Received: by 10.14.215.193 with SMTP id e41mr15331530eep.44.1345581608765; Tue, 21 Aug 2012 13:40:08 -0700 (PDT) Sender: sebastian.krebs.berlin@gmail.com X-Google-Sender-Delegation: sebastian.krebs.berlin@gmail.com Received: by 10.14.176.73 with HTTP; Tue, 21 Aug 2012 13:40:08 -0700 (PDT) In-Reply-To: <5032A163.9040500@toolpark.com> References: <5032A163.9040500@toolpark.com> Date: Tue, 21 Aug 2012 22:40:08 +0200 X-Google-Sender-Auth: d-2MgQIQ85zbyOP-2R5Wuk_WgL4 Message-ID: To: internals@lists.php.net Content-Type: multipart/alternative; boundary=e89a8f647ac3ce886a04c7cca1e9 Subject: Re: [PHP-DEV] Official Userland Library (was: removing an item from an array) From: krebs.seb@gmail.com (Sebastian Krebs) --e89a8f647ac3ce886a04c7cca1e9 Content-Type: text/plain; charset=ISO-8859-1 Hi, Nice to see my name not only in my signature ;) I've not much to say right now, but what you wrote was slightly in my mind, when I wrote the other mail. I'll keep an eye on it (at least ;)). Regards, Sebastian 2012/8/20 Lars Schultz > 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. > > 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. > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > --e89a8f647ac3ce886a04c7cca1e9--