> -----Original Message-----
> From: [email protected] [mailto:[email protected]] 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 <[email protected]>wrote:
>
> >
> >
> >
> > 2013/6/27 Tjerk Anne Meesters <[email protected]>
> >
> >> On Thu, Jun 27, 2013 at 4:27 PM, Florin Patan <[email protected]>
> >> 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