On Thu, Jun 27, 2013 at 7:13 PM, Richard Bradley <
[email protected]> wrote:
> > -----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".
>
To be clear, I'm not the person who proposed the patch, so I'm not the one
asking for opinions; I'm merely an engaged bystander if you will.
That said, "providing a single data point" which loosely translates to a
thumbs up or down and being non-constructive are not mutually exclusive
terms; the constructive element here refers to the value it adds to the
discussion. In other words, saying "Boo! -1" serves as a statistic, but a
good argument benefits the proposer most imo.
>
> > >> > 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.
>
>
This wasn't meant to be taken at face value; it was part of the argument
that some functions may not seem useful at first glance. I'm of course not
arguing that hypot() is simply added fluff, that's pretty clear from
referencing the man(ual) page, though for the fun of it you should search
for this function on stackoverflow to gauge how often it's used.
The same concerns do not apply to this affine transform, which is why it
> should not be in core.
>
Whether a C implementation is a hard requirement could be used as a
deciding factor, yes, but otherwise I wholeheartedly disagree with that
statement :) there are enough functions in the core that could be correctly
and in some cases also efficiently be implemented in userland.
>
> If there were sufficient demand for it, then it might justify a PECL
> extension. My impression is that there is not.
>
Indeed. Perhaps an extension dedicated to working with range operations in
general may be a useful addition. It would definitely be a good learning
experience, assuming said proposer would take up this job himself :)
>
> 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
>
>
--
--
Tjerk