>
>
> I have no strong opinion
> either way, but anyway it cannot work as is, because var_export
> already has a second optional parameter (bool $return = false).
>
Yes, I meant the third argument. I updated the RFC to reflect that. Sorry.
> Moreover the RFC currently says that var_export([1,
On Wed, Apr 8, 2020 at 9:37 AM Derick Rethans wrote:
>
>
It's different. Changing from long to short array syntax makes it
> unparsable by older versions of PHP.
>
All versions of PHP which don't support short array syntax have long been
EOL for nearly 5 years now. We can't possibly be expected
On Wed, Apr 8, 2020 at 9:22 AM Benjamin Morel
wrote:
> > VAR_EXPORT_NO_INDEX
>
> Note that I wouldn't consider a BC break to change var_export()'s
> behaviour to always discard indexes when they're numeric, I'm not sure this
> should even be an option!
>
>
Well, it might if people are testing the
2020 at 5:19 PM Sherif Ramadan
wrote:
>
>
> On Fri, Apr 3, 2020 at 5:16 PM Andrea Faulds wrote:
>
>> Hey Sara,
>>
>> Sara Golemon wrote:
>> > On Mon, Mar 30, 2020 at 12:38 PM Chase Peeler
>> wrote:
>> >
>> >> Just out of cur
On Fri, Apr 3, 2020 at 5:16 PM Andrea Faulds wrote:
> Hey Sara,
>
> Sara Golemon wrote:
> > On Mon, Mar 30, 2020 at 12:38 PM Chase Peeler
> wrote:
> >
> >> Just out of curiosity, is there any reason we couldn't add an optional
> >> parameter called "$short_array" or whatever that defaults to fal
On Mon, Mar 30, 2020 at 1:19 PM Sara Golemon wrote:
> On Mon, Mar 30, 2020 at 10:56 AM Sherif Ramadan
> wrote:
>
>> @Sara Golemon
>>
>>
>>> Ditto Danack's question, adding: "Then why not use brick/varexporter?"
>>>
>>> -S
>
>
> Aesthetics are irrelevant for a computer.
>
> This change does not improve anything and only breaks compatibility. Bad
> idea.
>
>
I beg to differ. While code may be meant for execution by a machine it is
actually intended for human consumption. Aesthetics matter to a human
reading the code.
@Sara Golemon
> Ditto Danack's question, adding: "Then why not use brick/varexporter?"
>
> -Sara
>
I punt the question back to you and ask why not use PHP?
@Dan Ackroyd
> That's an aesthetic choice, which not everyone will agree with.
>
Yes, I freely state that in the RFC. Everyone is free to vote how they like.
>
> "There shouldn't be any backwards incompatible changes"
>
> It apparently breaks 25 tests that compare the output of var_export
> w
e:
> > Hi Sherif,
> >
> > Sherif Ramadan wrote:
> >> I'm proposing a new RFC to change var_export()'s array syntax to use the
> >> short hand array syntax instead.
> >>
> >> The RFC is available here
> >> https://wiki.php.net/r
I'm proposing a new RFC to change var_export()'s array syntax to use the
short hand array syntax instead.
The RFC is available here https://wiki.php.net/rfc/var-export-array-syntax
This is a forwards-compatible change proposed for and targeting PHP 8.0.
I'd like to open up discussion.
I might be off here, but I believe the issue with that is that it's a
performance problem. You would have to check each key and function
parameter for a match, which would be slow.
You can, however, achieve what you're after just by using an array without
any packing/unpacking.
function foo(Array
ray exceeds
>>> size". Until someone does that, I cannot document it.
>>
>>
>> I cannot disagree more with this statement.
>>
>> - Marcos
>>
>> 2018-08-01 16:29 GMT-03:00 Sherif Ramadan :
>>
>>> It's undocumented, because it&#x
It's undocumented, because it's considered undefined behavior. PHP arrays
implicitly store the number of elements internally as an unsigned 32 bit
integer (regardless of architecture). This means that (technically) you
can't create an array with more than ((2**31) - 1) elements (or
2,147,483,647 el
On Sat, Dec 2, 2017 at 3:44 PM, Alexei Gerasimov
wrote:
>
>
> > Let's not forget PHP 5 has been around for over a decade before PHP 7
> even
> > showed up. There are still a lot of old code basis that've been running
> in
> > PHP 5 for years. And for large code basis with deep rooted legacy, it i
On Sat, Dec 2, 2017 at 3:08 PM, Alexei Gerasimov
wrote:
>
> I don't think we should be worried about changes _other_ projects would
> have to make to cope up with language evolution lest it becomes an
> (unnecessary and surrogate) obstacle. My vision is that if some
> company/group produces an ID
I think we get this "I want to make PHP more like " thing more
often than any other language change proposals. I'm not strictly opposed to
the idea of borrowing from other languages. Though when the thesis
statement is almost exclusively about making PHP feel more like than anything else I'd rathe
There have already been several such proposals made in past years, and
discussed at length here on the mailing list.
See C# Style Accessors past RFC:
https://wiki.php.net/rfc/propertygetsetsyntax-v1.2
and alternatives:
https://wiki.php.net/rfc/propertygetsetsyntax-alternative-typehinting-syntax
I would definitely vote C as well. PHP 7's behavior makes even less sense
than PHP 5 in this case.
On Tue, Mar 14, 2017 at 10:43 PM, Sara Golemon wrote:
> This comes in thanks to my old friend Fred Emmott on the HHVM project:
> https://3v4l.org/vUHq3
>
> class Foo {
> const A = 1 << 0;
>
-03-12 13:03 GMT+05:00 Sherif Ramadan :
>
> how it pertains to this discussion
> >
>
> This is example of type matching from my first message.
>
> I'm not sure what that has to do with inheritance
> >
>
> Yes, this is not related with inheritance. But order
I'm not sure what that has to do with inheritance exactly or how it
pertains to this discussion. This is an implementation detail.
On Sun, Mar 12, 2017 at 3:47 AM, Michael Vostrikov <
michael.vostri...@gmail.com> wrote:
> 2017-03-12 12:19 GMT+05:00 Sherif Ramadan :
>
> >
Which requirements are those exactly?
On Sun, Mar 12, 2017 at 3:15 AM, Michael Vostrikov <
michael.vostri...@gmail.com> wrote:
> 2017-03-12 12:03 GMT+05:00 Sherif Ramadan :
>
>> You could have an abstract classes implement the interface and extend
>> from the abstract cl
You could have an abstract classes implement the interface and extend from
the abstract classes.
On Sun, Mar 12, 2017 at 1:57 AM, Michael Vostrikov <
michael.vostri...@gmail.com> wrote:
> 2017-03-12 11:41 GMT+05:00 Sherif Ramadan :
>
> > Yea, but how's that an improvement
Yea, but how's that an improvement over using an interface?
On Sun, Mar 12, 2017 at 1:38 AM, Michael Vostrikov <
michael.vostri...@gmail.com> wrote:
> > Example with Rectangle and Square IMO is an example of bad naming in this
> case.
>
> I used this example because this is known problem of inher
PHP already has horizontal inheritance. They're called traits.
How is this an improvement in anyway?
On Sat, Mar 11, 2017 at 1:36 AM, Michael Vostrikov <
michael.vostri...@gmail.com> wrote:
> Hello. I have an idea which seems rather useful. I would like to know your
> opinion,
>
> Let's say we h
This is only a test. Please ignore. Thanks.
On Wed, Mar 1, 2017 at 3:30 PM, Rene Veerman <
rene.veerman.netherla...@gmail.com> wrote:
> exec-sum : introducing a new URL notation scheme
>
> 2 examples :
>
> example 1 :
>
> http://localhost/tarot(deck'Original-Rider-Waite
> ',reading'3-Cards')/music(youtubePlaylist'ABCDEFG')
>
> parameters de
I'm pretty sure this is covered by the language reference [
http://php.net/language.types.float] as per precision of floating point
numbers in PHP. Though I don't see much harm in adding a note with
references there to the documentation for number_format(), if that's what
you meant.
On Fri, Nov 25
I really doubt this method will prove useful in practice for the use case
you mention, and for a number of a reasons.
1) The name is misleading (there is no real query string in the case of
native prepared statements - the SQL and data are always separate)
2) You would have to execute the statemen
On Sun, Sep 11, 2016 at 4:47 AM, Tony Marston
wrote:
> Sent: Saturday, September 10, 2016 7:47 PM
> >To: Tony Marston ; internals@lists.php.net
> >Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with
> composer/pickle
>
>
> Then I suggest that those who are so anxious to see of death o
Just testing that the mailing list is still working. Please ignore.
If I'm understanding this correctly, this change doesn't effect actual
behavior, right? It's just taking advantage of reusing code for
random_bytes / random_int ?
If that is true I don't think it much matters whether the change goes
through 7.0 or 7.1 since it has no real end-user impact.
On Sun,
I think this is the most awesomest fantastical idea since sliced bread.
+~0
On Thu, Oct 8, 2015 at 11:05 AM, Mattias Gonzalez wrote:
> I wanted to propose the "var_die($var)" functionallity.
> My mates and i use a lot var_dump($var);die;
>
> Since die() wont print an array just a string, i thin
, 2015 at 11:18 PM, Scott Arciszewski
wrote:
> Because $x exists.
>
> https://3v4l.org/kUJtP
> Scott Arciszewski
> Chief Development Officer
> Paragon Initiative Enterprises
>
>
> On Tue, Aug 25, 2015 at 11:16 PM, Sherif Ramadan
> wrote:
> > Yes, because all undefi
turns true when a
variable is null?
On Tue, Aug 25, 2015 at 11:13 PM, Scott Arciszewski
wrote:
> On Tue, Aug 25, 2015 at 11:11 PM, Sherif Ramadan
> wrote:
> > That's exactly what isset() does. isset/empty never raise errors.
> >
> > On Tue, Aug 25, 2015 at 1
That's exactly what isset() does. isset/empty never raise errors.
On Tue, Aug 25, 2015 at 11:09 PM, Scott Arciszewski
wrote:
> Hi everybody,
>
> Would anyone be interested in adding another helper like
> isset()/empty() simply called exists() which would return true if the
> variable is defined
ter), so now I've been waiting until 7.0 is clear (as
> well as me having the time to finish drafting the RFC).
>
> AllenJB
>
>
>
> On , Sherif Ramadan wrote:
>
>> Hey Nicolai,
>>
>> You're right. The notice is triggered by array_push behavior only
Hey Nicolai,
You're right. The notice is triggered by array_push behavior only, which
means that $x = true; echo $x['foo']; doesn't trigger the notice, which is
the same as your code above. Only write operations have historically
resulted in this notice.
I would agree that providing the notice wo
On 22/08/2015 02:38, Sherif Ramadan wrote:
>
>> I see. So you're not actually doing overflow checks then? Because at the
>> point you'd be checking this zend_long or size_t it could have already
>> overflowed or wrapped. The subject may have misled me to understan
On Fri, Aug 21, 2015 at 6:22 AM, Anatol Belski
wrote:
>
>
> > -Original Message-
> > From: Sherif Ramadan [mailto:theanomaly...@gmail.com]
> > Sent: Friday, August 21, 2015 12:00 PM
> > To: Anatol Belski
> > Cc: Dmitry Stogov ; Xinchen Hui ;
>
not at all sure how (zlong) <
(zend_long)INT_MIN will ever detect an overflow.
On Fri, Aug 21, 2015 at 5:40 AM, Anatol Belski
wrote:
>
>
> > -Original Message-
> > From: Anatol Belski [mailto:anatol@belski.net]
> > Sent: Friday, August 21, 2015 11:38
Maybe I'm missing something here, but how do these macros detect overflow
exactly? If the check is done on the actual result and not the operands
then it's not a good overflow check. Additionally, why wouldn't overflow
checks be needed on 32-bit architecture, or any other architecture for that
matt
A good learning opportunity for "You shouldn't rewrite history because the
consequences can be dire!" ;-)
Also, you want php-webmaster for internal infrastructure, not php-dev, but
I understand you may have felt our message wouldn't get through with all
the flood of emails spawned by that forced p
> "The learned man aims for more. But the wise man decreases. And then
> decreases again."
>
>
>
>
>
> *From:* Sherif Ramadan [mailto:theanomaly...@gmail.com]
> *Sent:* Monday, July 20, 2015 5:43 PM
> *To:* Elmer Beardshall
> *Cc:* php-webmas...@lists.php
On Sun, Jul 5, 2015 at 4:39 PM, Levi Morrison wrote:
>
>
> I just want to chime in and say that I have a contributed to a popular
> application written in C that actually uses division by zero in a
> useful manner. I feel like the rest of you think this is solely a
> programmer error, and wanted
On Sun, Jul 5, 2015 at 6:29 AM, Dan Ackroyd wrote:
> On 4 July 2015 at 20:56, Sherif Ramadan wrote:
> >
> > I'm proposing that we reconsider removing the warning from floating point
> > division and here's why.
>
> Wait what? I don't remember
Hey guys,
I'm proposing that we reconsider removing the warning from floating point
division and here's why.
While IEEE 754 defines special values for floating point arithmetic when
division by zero occurs, there's nothing stopping the language from
providing useful error information to the user,
+1 from google...@php.net
On Tue, Jun 30, 2015 at 1:42 AM, Aaron Piotrowski wrote:
> Quickly applying bug fixes.
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
On Fri, Nov 7, 2014 at 4:49 PM, Stas Malyshev
wrote:
> Hi!
>
>
> So the question here is how common is the case of PUT+mulitpart/form-data?
>
Well, that's what I'm trying to establish. Based on the information I have
available, there have been a few dated bug reports asking for this. There
are
On Fri, Nov 7, 2014 at 12:47 AM, Will Fitch wrote:
>
> On Nov 7, 2014, at 12:38 AM, Sherif Ramadan
> wrote:
>
>
>
> On Fri, Nov 7, 2014 at 12:23 AM, Will Fitch wrote:
>
>>
>> Sherif - I’m just going to be straight here. I haven’t seen support for
>>
On Fri, Nov 7, 2014 at 12:23 AM, Will Fitch wrote:
>
> Sherif - I’m just going to be straight here. I haven’t seen support for
> your proposal at all in this thread. You continue to try and make this
> case, but it continues to be shot down with absolutely valid issues, and
> your only responsiv
On Thu, Nov 6, 2014 at 7:56 PM, Andrea Faulds wrote:
>
> > On 7 Nov 2014, at 00:53, Stas Malyshev wrote:
> >
> > Hi!
> >
> >> Again, I think you're oversimplifying the problem. For one, you don't
> know
> >> that the payload is JSON unless you check the Content-type header
> yourself,
> >> and y
On Thu, Nov 6, 2014 at 7:53 PM, Stas Malyshev
wrote:
> Hi!
>
> > Again, I think you're oversimplifying the problem. For one, you don't
> know
> > that the payload is JSON unless you check the Content-type header
> yourself,
> > and you really shouldn't have to since PHP could easily do this for y
On Thu, Nov 6, 2014 at 6:42 AM, Sanford Whiteman
wrote:
> Prove I "believe a multipart/form-data mime cannot be sent along with a
> PUT request" using messages I have sent to this list. You are basically
> lying for effect at this point. I never said that, took pains to explain
> that I am not s
On Thu, Nov 6, 2014 at 4:56 AM, Sanford Whiteman
wrote:
> > PUT is not intended to necessarily store the request entity body on the
> file
> > system. Its intention is to store the entity body at the request URI.
>
> I never said it was. I used the expression "store at the URI" about
> 10 ten ti
On Thu, Nov 6, 2014 at 4:32 AM, Sanford Whiteman
wrote:
>
>
> > First of all, RFC 1867 is not a standard. It's an experimental protocol
> > definition.
>
> Oh nonsense. You know very well that RFC 1867 conformance is an
> industry standard for file uploading When 2388 says "originally set
> out
On Thu, Nov 6, 2014 at 3:20 AM, Sanford Whiteman
wrote:
> > Nowhere did I suggest that the request verbs themselves (i.e. PUT and
> POST) have the same intent. Just
> > that the handling of multipart-form data is not specific to either one of
> > those verbs.
>
> Define "handling." :/
>
Specific
On Thu, Nov 6, 2014 at 2:44 AM, Sanford Whiteman
wrote:
> > The HTTP specification doesn't restrict how the request body is encoded
> > based on the request verb.
>
> I never said it did... please don't put words in my mouth.
>
> As Will notes, you're sidestepping the point, which standards-savvy
On Wed, Nov 5, 2014 at 10:53 PM, Will Fitch wrote:
>
> > On Nov 5, 2014, at 10:00 PM, Sherif Ramadan
> wrote:
> >
> >
> >
> > On Wed, Nov 5, 2014 at 9:36 PM, Will Fitch wrote:
> >
> >
> >
> > Easy - you have no idea what the input
On Wed, Nov 5, 2014 at 10:03 PM, Sanford Whiteman
wrote:
> For the umpteenth time, *in what situation must you PUT
> multipart/form-data or multipart/x-www-form-urlencoded only to treat it,
> semantically, as a POST*? Which UA cannot send a POST? It's like we're
> completely upside down on this t
On Wed, Nov 5, 2014 at 9:36 PM, Will Fitch wrote:
>
>
>
> Easy - you have no idea what the input type is from PUT without checking
> the incoming type. With POST, you know exactly what it is. PUT input code
> be JSON, multipart mime, a file or a whatever the dev wants.
>
That's not necessarily
On Wed, Nov 5, 2014 at 8:38 PM, Andrea Faulds wrote:
>
> > On 6 Nov 2014, at 01:29, Sherif Ramadan wrote:
> >
> > So you're actually describing two semi-different problems here. One is
> that PHP doesn't actually inform you of the HTTP request VERB strictly
On Wed, Nov 5, 2014 at 7:31 PM, Andrea Faulds wrote:
>
> > On 5 Nov 2014, at 22:29, Sherif Ramadan wrote:
> >
> > From all the people I've spoken with that have a problem with handling
> PUT
> > requests in PHP, it seems that they'd rather have PHP popu
08 AM, Patrick ALLAERT
wrote:
> 2014-10-30 19:23 GMT+01:00 Sherif Ramadan :
> > Hello Internals,
> >
> > I've been meaning to write up a full-blown RFC for introducing a new
> > standardized HTTP interface for PHP core for some time now. I figure now
> > with
On Fri, Oct 31, 2014 at 5:01 PM, Will Fitch wrote:
>
>
>
> I’m actually not suggesting an alternative - I’m suggesting this RFC isn’t
> an option.
>
>
Great, your suggestion has been noted. Thanks for your contribution to this
discussion! :)
On Fri, Oct 31, 2014 at 4:29 PM, Will Fitch wrote:
>
> On Oct 31, 2014, at 4:21 PM, Sherif Ramadan
> wrote:
>
>
>
> On Fri, Oct 31, 2014 at 4:16 PM, Will Fitch wrote:
>
>>
>>
>>
>> While not too specific to Rowan, reiterating the pecl/http approa
On Fri, Oct 31, 2014 at 4:16 PM, Will Fitch wrote:
>
>
>
> While not too specific to Rowan, reiterating the pecl/http approach is
> indirectly what your asking for? I have mentioned this numerous times, but
> you haven’t responded with a reason not to take this approach - which is an
> RFC that w
On Fri, Oct 31, 2014 at 3:35 PM, Rowan Collins
wrote:
> Sherif Ramadan wrote on 31/10/2014 18:52:
>
>> This RFC is about core PHP and I really don't care how
>> many competing ideas exist out there that are closely or mildly related to
>> this RFC.
>>
>
On Fri, Oct 31, 2014 at 3:00 PM, Larry Garfield
wrote:
> On 10/31/14, 1:52 PM, Sherif Ramadan wrote:
>
>>
>>
> This RFC has two primary goals in mind:
>>
>> 1) Expose the parsing/handling of the HTTP request to userland in a
>> consistent way
>>
>
So for the purposes of this discussion and in an effort to remain on-topic
and productive, let's keep all of the FIG/PSR and other third party efforts
out of the discussion unless it is intended to improve/help this particular
RFC. Please keep in mind that this is a PHP internals discussion and not
On Fri, Oct 31, 2014 at 1:32 PM, Florian Margaine
wrote:
> Hi,
>
> Le 31 oct. 2014 18:28, "Sherif Ramadan" a écrit
> :
> >
> > On Fri, Oct 31, 2014 at 1:09 PM, Rowan Collins
> > wrote:
> >
> > >
> > > Let me repeat my question
On Fri, Oct 31, 2014 at 1:09 PM, Rowan Collins
wrote:
>
> Let me repeat my question:
>
> Say I write a class "AwesomeHTTPReceive implements HttpMessageReceive",
> what do I then do with this class in order for it to perform any actions?
>
> How does PHP know that my class is the one it should pop
On Fri, Oct 31, 2014 at 12:04 PM, Andrea Faulds wrote:
>
>
>
> So there’s still a default implementation, then? So, if you want to parse
> in userland, how does that work? The default implementation fills in the
> variables and then your implementation parses it again, wasting CPU time
> and maki
On Fri, Oct 31, 2014 at 12:19 PM, Andrea Faulds wrote:
>
>
>
> I’m not sure I really see what it solves, though? Why should we allow
> users to implement their own slow parsers in userland? Why can’t we just
> have a single built-in parser like we’ve had the last two decades? I don’t
> see the po
On Fri, Oct 31, 2014 at 11:56 AM, Rowan Collins
wrote:
>
> I think the piece that's missing is how exactly these interfaces would
> interact with core, or rather with the SAPIs which handle the actual
> transfer of HTTP requests and responses.
>
PHP would have an HttpRequest class, as noted in t
On Fri, Oct 31, 2014 at 5:25 AM, Andrea Faulds wrote:
>
>
> This is no less of a backwards-compatibility headache. This still breaks
> every PHP app I have ever written.
>
>
To be perfectly clear, the default behavior would remain the same, so no
PHP app you have ever written would break. The dif
So far there seems to be a lot of concern around BC, and particularly
removing or getting rid of GPC superglobals. So I completely understand the
concerns and hope to address them as clearly as possible.
First, for the sake of BC I think removing the superglobals from the
language should not be do
On Thu, Oct 30, 2014 at 4:42 PM, Andrea Faulds wrote:
>
> > On 30 Oct 2014, at 20:33, Sherif Ramadan
> wrote:
> >
> > Yes, this proposal is intended to do two things. 1) Fix the
> aforementioned problems.
>
> By the sounds of things, it doesn’t fix these problem
On Thu, Oct 30, 2014 at 4:24 PM, Andrea Faulds wrote:
>
> > On 30 Oct 2014, at 19:49, Sherif Ramadan
> wrote:
> >
> > Well, let's look at how well providing implementation has worked out for
> > PHP so far.
> >
> > GPC variables are implementati
On Thu, Oct 30, 2014 at 2:30 PM, Florian Margaine
wrote:
>
>
> I find this very... useless. Sure, interfaces are not useless. But I don't
> think php-src is there to dictate what userland code should look like. It
> should provide *implementations*, not interfaces.
>
Well, let's look at how well
Hello Internals,
I've been meaning to write up a full-blown RFC for introducing a new
standardized HTTP interface for PHP core for some time now. I figure now
with PHP 7 on the road map this might be a good time to start this
discussion since it involves breaking some backwards compatibility that
On Mon, Sep 8, 2014 at 4:06 AM, Michael Wallner wrote:
> On 07/09/14 14:25, Andrea Faulds wrote:
>
> >
> > There’s actually a quite serious issue just now, which is that it
> > evaluates the first operand twice if it’s not empty. This is because
> > $a ?: $b is expanded to empty($a) ? $b : $a, su
Actually, we shouldn't be doing that all. We should simply just overwrite
the header. It wouldn't make much sense to set two headers with the same
cookie name when we can just overwrite it.
On Mon, Sep 8, 2014 at 2:50 AM, Tjerk Meesters
wrote:
> Hi!
>
>
> On Sat, Sep 6, 2014 at 5:38 AM, Florian
I've played around with this branch for a bit and seems reasonable, passes
the tests, and doesn't seem to have any serious issues/memories leaks
AFAICT.
I can't stress enough, however, how important it is for us to avoid
inconsistencies in behavior between various forms of syntax. This is often
so
+1
Kill it with fire and throw more gasoline ontop of the fire.
On Sun, Aug 31, 2014 at 8:08 AM, Tjerk Meesters
wrote:
> Hi Ferenc,
>
> On 31 Aug, 2014, at 7:00 pm, Ferenc Kovacs wrote:
>
> >
> >
> >
> > On Sun, Aug 31, 2014 at 7:08 AM, Tjerk Meesters <
> tjerk.meest...@gmail.com> wrote:
> >
Hi,
Someone pointed out to me recently that since the delimiters are not a
requirement of PCRE, and thus should not be considered a part of the
regular expression, there really is no need to escape them inside of the
regular expression such as that provided to preg_match functions and
similar.
I
On Thu, Sep 26, 2013 at 7:33 PM, Tjerk Meesters wrote:
>
>
>
> I didn't quite understand how the current implementation would have BC
> issues, though. Would you care to elaborate on that?
>
>
>
I didn't look at your actual implementation. I saw 3 constants and deduced
that one would be required.
On Thu, Sep 26, 2013 at 6:51 PM, Tjerk Meesters wrote:
>
>
> I deliberately chose these values so that I can simply specify `true` to
> mean pass both values. Bit masks seem cumbersome in this situation.
>
>
The default behavior is already to pass the value to the callback.
Requiring the argument
On Wed, Aug 7, 2013 at 10:29 PM, Damian Wadley wrote:
> I like how all the \"why I need a Git account\" reasons above
> are copied verbatim from the list of reasons one *doesn\'t* need a Git
> account :)
>
>
Well, you passed the first test.
After some digging and a little more thought I find that removing this
comment from the example in the docs at
www.php.net/language.operators.precedence does indeed cause more harm than
good. So I'm definitely wrong in saying that it should be removed.
However, I would like to acknowledge the conf
On Sat, Jul 20, 2013 at 3:37 AM, Stas Malyshev wrote:
> Hi!
>
> > I cannot believe this is true now, but I ask list before I fix doc.
>
> I don't think there's something that needs to be fixed. "Undefined"
> means "it depends on implementation and we do not want to commit to a
> specific behavior
ctive discussion, a revert is entirely appropriate and has nothing to
> do with placing one's opinion over another's. It has to do with placing
> the process of consensus building over unilateral cowboy commits.
>
Fair enough.
>
> -Sara
>
>
> On Fri, Jul 19, 2013
Sara,
On Sat, Jul 20, 2013 at 12:44 AM, Sara Golemon wrote:
> What's undefined isn't the relationship between preinc/postinc and add.
> What's undefined is the use of multiple preinc/postinc operators within a
> single expression
>
I'm sorry but I can not find any evidence of how that is undef
On Fri, Jul 19, 2013 at 11:56 PM, Sara Golemon wrote:
> On Fri, Jul 19, 2013 at 7:16 PM, Yasuo Ohgaki wrote:
>
>>
>>
>> If there aren't comments, I'll rewrite the example.
>>
>>
>> There were comments. I explicitly told you that that the behavior is
> defined as undefined. You CHOSE to ignore
On Fri, Jul 19, 2013 at 10:36 PM, Yasuo Ohgaki wrote:
> Hi Sheif,
>
> 2013/7/20 Sherif Ramadan
>
>> Then I would say that example is wrong, but people may find reason to
>> disagree. I'm basing my contention purely off what I see in php-src and the
>> document
On Fri, Jul 19, 2013 at 10:16 PM, Yasuo Ohgaki wrote:
> Hi Sherif,
>
> Thank you for your info!
>
> 2013/7/20 Sherif Ramadan
>
>> I don't see where there is a bug in the documentation, no.
>
>
> It is in doc's example code.
>
>
Then I would say
On Fri, Jul 19, 2013 at 8:55 PM, Yasuo Ohgaki wrote:
> Hi Sara,
>
> 2013/7/20 Sara Golemon
>
> > I would ask that you don't "fix" the docs, as we want to continue to
> > discourage users from engaging in unsafe behaviors.
>
>
> If precedence is implemented correctly, there should not be any ambi
On Thu, Jul 18, 2013 at 7:18 PM, Chris London wrote:
> I hear Perl 6 supports Str decrementing
>
>
I heard of Perl 6 once.
On Thu, Jul 18, 2013 at 3:54 AM, Lior Kaplan wrote:
> On Thu, Jul 18, 2013 at 4:21 AM, Sherif Ramadan
> wrote:
>
>> On Wed, Jul 17, 2013 at 6:47 PM, Lior Kaplan wrote:
>>
>>> What do you think about closing older PR ( > 28 days) ?
>>>
>>
>&g
On Thu, Jul 18, 2013 at 1:37 AM, Pierre Joye wrote:
> On Thu, Jul 18, 2013 at 6:19 AM, Sherif Ramadan
> wrote:
> > On Wed, Jul 17, 2013 at 11:55 PM, Yasuo Ohgaki
> wrote:
> >
> >> Hi all,
> >>
> >> Take a look at this PR
> >>
> &
1 - 100 of 230 matches
Mail list logo
