> -----Original Message----- > From: tjerk.meest...@gmail.com [mailto:tjerk.meest...@gmail.com] On Behalf Of > Tjerk Anne Meesters > Sent: 27 June 2013 11:24 > To: Sebastian Krebs > Cc: Florin Patan; Jeremy Curcio; PHP Internals > Subject: Re: [PHP-DEV] Gauging Interest:RFC to add map() function > > On Thu, Jun 27, 2013 at 5:43 PM, Sebastian Krebs <krebs....@gmail.com>wrote: > > > > > > > > > 2013/6/27 Tjerk Anne Meesters <datib...@php.net> > > > >> On Thu, Jun 27, 2013 at 4:27 PM, Florin Patan <florinpa...@gmail.com> > >> wrote: > >> > >> > On Thu, Jun 27, 2013 at 10:17 AM, Tjerk Anne Meesters > >> > > >> > May I kindly ask why all the PHP users would want this function in > >> > the core? > >> > > >> > >> Are you meaning to ask why would *any* php user want this function in > >> the core? As with most things, the need of one may be shared among a > >> critical mass that could swing the balance. In practice though, the > >> critical mass is usually determined by the internals peeps :) > >> > > > > But this method is _really_ quite special, isn't it? I cannot imagine, > > that there is "critical mass", that needs this _in core_. > > > > I'm not casting any judgement on its usefulness; I'm merely arguing the > "why should this be in core? I would never use it." narrative is not > constructive.
It can serve as an indication of which way the he would vote if this came to RFC. It can give a single data point towards how many people would find this useful. You did ask what people thought of the proposed method. I don't think you should simply reject negative answers as "not constructive". > >> > And as I understand, PHP delegates the math stuff to the underlying > >> > C implementation so why would it be faster having it in PHP core > >> > rather that in PHP userland? > >> > > >> > >> Performance is not the only reason why features make it into the > >> core; it's providing a rich set of built-in features to make the > >> developer's lives easier, such as the latest password hashing API > >> which is easy to get wrong or generators that reduce boiler plate > >> code. > > > > You cannot compare language features (generators) with functions. And > > "security" is always a topic on its own. > > > > I consider new functions as a feature of the language as well, so there's no > need to make comparisons. > > That said, would you have guessed (without looking at the manual) that PHP > exposes a > "hypot($x, $y)" where you could otherwise have written "sqrt($x * $x, $y * > $y)"? > > Okay, it's a translation from <math.h> of course, but it came as a surprise > to me :) There is a good reason to have "hypot" in the C layer -- it is not possible to implement it in PHP correctly (and efficiently), due to overflow concerns. See http://en.wikipedia.org/wiki/Hypot for a summary. The same concerns do not apply to this affine transform, which is why it should not be in core. If there were sufficient demand for it, then it might justify a PECL extension. My impression is that there is not. Best, Rich Richard Bradley Tel : 020 7485 7500 ext 3230 | Fax : 020 7485 7575 softwire Sunday Times Best Small Companies - UK top 20 three years running Web : www.softwire.com | Addr : 325 Highgate Studios, 53-79 Highgate Road, London NW5 1TL Softwire Technology Limited. Registered in England no. 3824658. Registered Office : 13 Station Road, London N3 2SB -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
