concerned. This is nothing to worry about IMO - any decent XML parser
treats them the same.
- Davey
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
with mem leaks.
- Davey
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
It doesn't compile with 5.0.x
But thats nothing to do with the memleaks.
- Davey
Jani Taskinen wrote:
On Tue, 5 Apr 2005, Davey wrote:
As Wez knows, there are issues with OSX/PHP 5.0.x/PDO, so on
What issues?
--Jani
--
PHP Internals - PHP Runtime Development Mailing List
To unsubs
mailing list are tired of having to commit my changes for me.
Thanks
- Davey
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
y a default function (say, a logger).
There is currently a rather large (and heated) debate on pear-dev about
how to not get in a mess with PHP5 error handling, and I have proposed
a nice solution (IMO) which relies on the behaviour I propose.
- Davey
--
PHP Internals - PHP Runtime Development Maili
lt;<11L)) then add E_DEPRECATED to the
#define E_ALL (E_ERROR | E_WARNING | E_PARSE | E_NOTICE | E_CORE_ERROR |
E_CORE_WARNING | E_COMPILE_ERROR | E_COMPILE_WARNING | E_USER_ERROR |
E_USER_WARNING | E_USER_NOTICE | E_DEPRECATED)
- Davey
--
PHP Internals - PHP Runtime Development Mailing List
To uns
n the first place) here
http://bugs.php.net/23849, it shows my progress - do you want to take
over that as I am now looking to change a whole bunch of docs related to
the callback stuff... if you could take this bug off my hands that would
be great.
- Davey
--
PHP Internals - PHP Ru
Justin Hannus wrote:
So it seems like to get the same functionality, in userland, why not just:
$_APPLICATION = &$_SESSION
-Justin
Uh... then its still only on a session basis.
- Davey
"Davey" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Wojtek Meler
ong) that behaves *exactly* like $_SESSION (in
assignment etc) except that its values are available not across
sessions but across applications and instances of applications.
- Davey
Andrey Hristov wrote:
Hi Davey,
I don't know whether this will be implemented in an extension but
th
t wrap $_SESSION and force a SESSION SID is if you want
SESSION vars *and* APPLICATION vars in the same script, you'll run into
problems... cause you cannot run simulatenous sessions and you certainly
cannot switch when you write to a different var.
- Davey
--
PHP Internals - PHP Runtime De
Stefan Walk wrote:
On Thu, Aug 07, 2003 at 02:15:12PM +0100, Davey wrote:
Andrey,
This isn't quite as transparent as $_SESSION is and $_APPLICATION would
also not be a superglobal. What I would like to see at the end of this
is a $_APPLICATION variable (or $_APP? some poeple complained
Ilia Alshanetsky wrote:
On August 7, 2003 04:35 pm, Davey wrote:
You've hit the nail on the head! By literally copying and pasting the
$_SESSION code over, s/_SESSION/_APPLICATION and forcing the SID to be a
certain thing, you pretty much implement what I want. The reasons you
cannot just
en it can be
considered for core after it has had some real-life testing/scenarios
thrown at it?
Just to make it clear, I don't know C/C++ at all, this is just an idea
that you might or might not like to implement, I cannot do it (I had
help with the MD5 stuff ;).
- Davey
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
k that the $_APPLICATION variables should have exactly the same
life expectancy and garbage collection as $_SESSION variables currently
do, though they should be set independantly. Just as with $_SESSION you
can have more control by using your own "user" method to store the data.
- Davey
Wojtek Meler wrote:
Davey wrote:
MMCache can be used as a session handler, but this still has the
pitfalls of the other solutions.
If you were to implement $_APP(LICATION) as suggested, then it could
indeed (in theory) use MMCache, just as $_SESSION does
- Davey
As far as I understand you
and papers will be selected by
January 20th.
We look forward to your submissions, and if you have any questions feel
free to e-mail me.
- Davey
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi,
I was trying to come up with an example for the
https://wiki.php.net/rfc/internal_constructor_behaviour RFC and noticed
some unexpected behavior.
Based on one of the examples:
In PHP 5.6 it will emit a Warning, and returns a unusable instance of
ReflectionFunction, the latter of which shou
Aug 14, 2015 at 4:42 AM, Anatol Belski
wrote:
> Hi Davey,
>
> > -Original Message-
> > From: m...@daveyshafik.com [mailto:m...@daveyshafik.com] On Behalf Of Davey
> > Shafik
> > Sent: Thursday, August 13, 2015 7:01 PM
> > To: internals@lists.php.net
> &g
backed value, that is:
function foo(Bar $bar): void { }
Where Bar is:
enum Bar: string {
case BAZ = 'baz';
case BAT = ‘bat';
}
And you can call `foo()` like: foo(‘baz’) and Bar::BAZ will be passed in.
I realize I’m opening a barn down here, but I just don’t see file-local type
aliases as that useful, and while I like the functionality of type-class-likes,
I think they would add more non-class behavior (in addition to enums) for
things that look like classes if we don’t add some sort of identifier. I’d much
rather that we add backed-value to enum casting, and at least make that more
consistent with this functionality if we’re going to conflate the syntax.
- Davey
> On Sep 7, 2024, at 06:28, Larry Garfield wrote:
>
> On Fri, Sep 6, 2024, at 7:46 PM, Davey Shafik wrote:
>
>> My main struggle with this is readability. As much as I want custom
>> types (and type aliases is a good chunk of the way there), the main
>> issu
Thats right, theres just bugs in the currect PECL releases and I
couldn't get CVS to compile with 5.0.x. Thinking on it now, CVS HEAD
is probably 5.1 only right? and theres a 5.0.x branch? ::looks::
Regardless, are these memory leak reports of any use?
- Davey
Wez Furlong wrote:
Rubbish.
Add a third php.ini, php.ini-dev
This should have the preferred settings for a development environment
- Davey
Jani Taskinen wrote:
Perhaps you should have noticed that the errors in php.ini-recommended
are logged so whatever the error level is shouldn't matter.
And I
Andi,
I have 15 failed tests on Ubuntu Hoary
Full details: http://news.php.net/php.qa/25118
- Davey
Andi Gutmans wrote:
Hi,
You can reach Beta 2 at http://snaps.php.net/~andi/
If there are no surprise show stoppers I'll put it live tomorrow evening.
Andi
--
PHP Internals - PHP Ru
only check "real" methods
at the very least? Or some way to additionally distinguish between these
two things?
- Davey
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
As little as it means, +1
- Davey
Rasmus Lerdorf wrote:
Since we are breaking a lot of stuff in 6.0, at least with
Unicode_semantics=On I am wondering if it may not be time to break some
more stuff and do a bit of spring cleaning. It would mean many apps
would need some work to work on PHP 6
t blanket and lets see if this does help in
practice.
- Davey
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
bad as if we added an optional
argument to ini_get() that would also
set the value.
I know we're already into PHP 5.3 alpha, but this is a simple alias,
so I'm hoping you can squeeze it in.
If not, I understand, and will leave that decision to the RM :)
- Davey
If the patc
I'll see if I can write this as a patch instead; I was trying for
"path of least resistance"
Should be a fun exercise for me! Will get to it tonight.
- Davey
On Mon, Aug 4, 2008 at 7:14 AM, Hannes Magnusson
<[EMAIL PROTECTED]> wrote:
> On Mon, Aug 4, 2008 at 13:02, J
e a better option in that
we
cannot return the previous "value" like ini_set().
I had suggested a second optional argument that could be assigned the
resource (context), and then return true. Though I still think that
returning
the resource is the best option.
- Davey
On Aug 6, 2008, at 03:47 AM, Hannes Magnusson wrote:
On Wed, Aug 6, 2008 at 06:24, Davey Shafik <[EMAIL PROTECTED]> wrote:
OK, here's an attempt at a patch[1], I discussed it briefly with
Johannes
and he felt some discussion was needed with regards to the return
value.
I pers
On Aug 6, 2008, at 11:38 AM, Hannes Magnusson wrote:
On Wed, Aug 6, 2008 at 15:11, Davey Shafik <[EMAIL PROTECTED]> wrote:
On Aug 6, 2008, at 03:47 AM, Hannes Magnusson wrote:
On Wed, Aug 6, 2008 at 06:24, Davey Shafik <[EMAIL PROTECTED]> wrote:
OK, here's an attempt
On Aug 6, 2008, at 11:38 AM, Hannes Magnusson wrote:
On Wed, Aug 6, 2008 at 15:11, Davey Shafik <[EMAIL PROTECTED]> wrote:
On Aug 6, 2008, at 03:47 AM, Hannes Magnusson wrote:
On Wed, Aug 6, 2008 at 06:24, Davey Shafik <[EMAIL PROTECTED]> wrote:
OK, here's an attempt
valid. It also says it's case-insensitive also, however I
doubt
that could be handled in any non-impactful way.
- Davey
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Why not just re-use the same highlight.*, they can be colors or classes...
or
you switch this based on "highlight.use_external_styles". You could also
add a: "highlight.add_stylesheet"
to add a default stylesheet created by PHP...
- Davey
Lewis Wright wrote:
Why not
I very much like this — though I would say it was dependent on the nullable
types RFC (like splat and variadics were codependent).
While I would like to see the introduction of a void type, I understand and
respect the limitations on the RFC.
However, one thing that I do think is missing, is the
ATED when it's set to 1 (as
you are actively trying to use the feature).
Thoughts?
Thanks,
- Davey
ch, carry on. This doesn't
work for say, the 5.3.x branch fixes getting pushed into trunk, the
5.3.x branch is toast as far as SVN is concerned once you merge the
first fix — quite useless.
- Davey
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
PHP_EOL is \n on OS X. So the \r worries are not a
concern. PHP_EOL would be fine in this case, assuming
the OSX sendmail is fine with it.
- Davey
On Aug 21, 2009, at 03:11 PM, Joey Smith wrote:
3) I don't have an Apple platform for testing, what will happen on
Mac if PHP_EOL is used a
On Mar 27, 2010, at 3:59 PM, Bharat Nagwani wrote:
> I might have missed earlier emails. How about this?
>
> $myLongNameObject = new myLongNameObject {
>property1: '1',
>property2: '2',
>property3: '3',
>property4: '4',
>property5: '5',
> };
>
> Can we av
From the manual:
T_PAAMAYIM_NEKUDOTAYIM :: ::. Also defined as T_DOUBLE_COLON.
http://php.net/manual/en/tokens.php
T_PAAMAYIM_NEKUDOTAYIM is hardly un-google-able.
- Davey
On Apr 27, 2010, at 2:50 AM, mathieu.suen wrote:
> Hannes Magnusson wrote:
>> On Mon, Apr 26, 2010
The point is that json_encode will automatically call and use the return of
jsonSerialize()
no matter WHERE you serialize the object.
This is great when you're JSONifying objects when working with frameworks etc.
- Davey
On May 13, 2010, at 6:29 PM, Jared Williams
all-null option
This has the added benefit of being as global as you like, and no need to keep
passing the IV to encrypt/decrypt
all over the place. It has the potential of clashing when you bring multiple
codebases together however (i.e a framework).
Possible to limit to a single namespace
variable was cast
however,
is that something we can store in the ZVAL and pull out with a function? (only
the type
casting that occurs due to this mechanism, not any other). I don't think this
is useful
enough for any kind of performance hit mind you ;)
- Davey
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ing to objects other than stdClass, so I don't think
it conflicts that
there is no:
function foo( (DBAdapter) $bar) { }
- Davey
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On May 26, 2010, at 5:20 PM, Zeev Suraski wrote:
> At 23:44 26/05/2010, Davey Shafik wrote:
>
>> On May 26, 2010, at 3:08 PM, Zeev Suraski wrote:
>>
>> > At 21:12 26/05/2010, Pierre Joye wrote:
>> >> As PHP's type system is seen as a big plus,
>&g
hould be removed, unless it's impeding further
innovation (a la namespaced old style constructors).
- Davey
On Jul 22, 2010, at 6:54 PM, Karoly Negyesi wrote:
> Hi,
>
> Given that call_user_func exists I would recommend to remove $foo()
> from PHP Next.
>
> Obser
o BC breaks), 6.0 (BC breaks).
Non-agreed upon enhancements, potential BC breaks, all should be done in
feature branches. This gives people buildable
(hopefully) branches to use for testing, revision control for those developing
the features, and unmuddied commit histories
to more easily pull
On Nov 25, 2010, at 9:05 AM, Derick Rethans wrote:
> On Thu, 25 Nov 2010, Davey Shafik wrote:
>
>> The goal then was to essentially take the 5.3 branch, create a 5.4
>> branch, cherry pick commits to trunk and apply them to the 5.4 branch
>> and end up with a sta
= $result->getColumn();
if ($this->count == 0) {
return false;
}
return false;
}
}
Not an ideal example, but it gives you an IDEA off the top of my head of a way
to take advantage of it
- Davey
On Nov 30, 2010, at 7:31 PM, presid...
2010/12/15 Julien Pauli
>
> Well, I would say that if your problem is memory, you should consider
> threads as they all share the same memory space in their process.
>
> Apache's children can weight very heavy if PHP's been compiled to
> support lots of extensions, you can happen with ~40/50Mb per
>> Nonetheless, it's a significant undertaking to deal with the complexity of
>> the language. There are dozens of tiny little edge cases in PHP's parsing
>> that require bunches of extra parser rules. An example from above is the
>> difference between using "statement" and "inner-statement" for
tags, or relying on
magic_quotes* etc. Of course, sane defaults when creating phars, is
something we can decide on as things move on, I would vote for having
both PHP_Archive and the --extract flag code inserted by default, this
would solve the issues IMO.
- Davey
Gregory Beaver wrote:
Hi
s like S9Y, FUDForum,
phpMyAdmin where the *typical* usage is not to serve a large number of
users, this is usually not an issue.
These techniques work just fine.
- Davey
Marcus Boerger wrote:
Hello Andi,
Friday, May 4, 2007, 9:55:23 PM, you wrote:
I think phar is a nice idea but honestly h
ny detriment (though not knowing what else that particular machine is
used for, I wouldn't say to move bugs.php.net itself over, just giving
an idea of size and scale :)
- Davey
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
n each request obviously isn't a problem for them.
Because sometimes you like to not waste resources unnecessarily? Maybe
because their host only allows default PHP config and doesn't provide
PEAR or PECL?
- Davey
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ce improvements,
especially when factoring in SSL:
379 HTTP SSL requests
Using HTTP/2 in serial: 63.293796062469 (HTTP/1.1 in serial should be even
slower)
Using HTTP/1.1 with curl_multi: 12.383034944534
Using HTTP/2 w/multiplexing: 2.7933928966522
Thanks,
- Davey
> On Sep 5, 2015, at 02:00, Kalle Sommer Nielsen wrote:
>
> Hi Davey
>
> 2015-09-02 7:31 GMT+02:00 Davey Shafik :
>> Hi,
>>
>> I've been poking around at HTTP/2 a lot lately, and it seems that so long
>> as you are using libcurl 7.43.0+ it's
array or something?
I'd rather not be creating _new_ resources, but ext/curl obviously has a
precedence of using them, so it would fit the UX.
Any thoughts? I'd love to get this into PHP 7.1 (or before, if possible!).
Thanks,
- Davey
I was unable to refactor out successfully to it's own
function. Plus, on the whole it seems incredibly untidy to me.
Feedback welcome!
- Davey
[1]
https://github.com/php/php-src/compare/master...dshafik:curl-http2-push#diff-ab7a9164033bd55887d45d0a6cb837eeR529
[2]
https://github.com/php/ph
Forgot to mention, if you'd like to try this patch for yourself, check out
my Docker container stuff here (with instructions :):
https://github.com/dshafik/php-http2-push-example
On Wed, Nov 18, 2015 at 5:31 PM, Davey Shafik wrote:
> Hey folks,
>
> I'd like to introduce a n
On Wed, Nov 18, 2015 at 6:34 PM, Davey Shafik wrote:
> Forgot to mention, if you'd like to try this patch for yourself, check out
> my Docker container stuff here (with instructions :):
> https://github.com/dshafik/php-http2-push-example
>
> On Wed, Nov 18, 2015 at 5:31 PM,
Hi,
On Mon, Nov 23, 2015 at 10:30 AM, Rowan Collins
wrote:
> Ben Scholzen 'DASPRiD' wrote on 23/11/2015 01:57:
>
>> On 13.11.2015 12:59, Bob Weinand wrote:
>>
>>> The alternative is replacing the resources by proper objects, without
>>> methods and public properties.
>>> Then we could integrate
On Tue, Nov 24, 2015 at 1:00 AM, Sebastian Bergmann
wrote:
> On 11/23/2015 10:10 PM, Anatol Belski wrote:
>
>> c) do RC8, release on 3rd, expect there are no bugs come in
>>
>
> +1
+1
On Mon, Nov 30, 2015 at 10:35 AM, Ferenc Kovacs wrote:
> > PHP's certs are also "broken" for
> > svn.php.net and edit.php.net, there are browser warnings because of the
> > SHA1 certificate signatures.
> >
>
> those are separate issues, already reported on syst...@php.net
> these kind of problems
follow up
with her specifically to get an opinion on the implementation.
Assuming she has no issues, I'd like to talk about moving forward with a
vote soon.
On Sun, Nov 22, 2015 at 12:14 PM, Davey Shafik wrote:
> On Wed, Nov 18, 2015 at 6:34 PM, Davey Shafik wrote:
>
>> Forgot
Frankly, I think the LTS distros that include PHP 5.6 will be plenty — as
we've seen with 5.3, it has been maintained with back ports long after the
official EOL.
People either understand what they're getting into when making these
choices, or they don't and they don't care anyway.
I'd vote +1 on
will end in 2 weeks, closing at 13:00 UTC on Wed 2015-12-23.
Thanks,
- Davey
You mention no support for numeric strings, but how will settype($string,
int|float), intval(), floatval(), is_numeric() and ctype_digit() work with
this change?
I do think if you don't change the semantics for strings to number
conversion (which I agree you can't due to BC breaks) there should be
tp2…), userland HTTP/2 clients, pecl_http (if that's
still a thing), etc.
Now, I don't think I have the ability to achieve this, but I'm willing to
give it a go.
At the very least, I'm more than happy to write up the RFC and work with
someone on this.
Thoughts?
- Davey
[1]
I would love to see all of the is_* methods implemented in the initial
implementation, these are far more useful to me than the basic math
operators.
As for interfaces, I'm generally pro-interfaces as programmatic
documentation if nothing else — however, none of the magic methods have
implemented
Hi Andrea
On Mon, Jan 4, 2016 at 5:16 PM, Andrea Faulds wrote:
> Hi Davey,
>
> Davey Shafik wrote
[snip]
We could also add a flag (e.g. --[no-]http2) on the CLI for
>> enabling/disabling it — this would be helpful for testing HTTP/2 client
>> fallback when it's not s
a new SAPI from scratch —
is there a good SAPI I can use as an example to learn that side of things?
Would anyone be interested in taking this on for 7.1? or pairing/mentoring
on it?
- Davey
[1] https://www.mail-archive.com/internals@lists.php.net/msg82237.html
On Jan 19, 2016, at 6:21 AM, Derick Rethans wrote:
>
>> On Mon, 18 Jan 2016, Davey Shafik wrote:
>>
>> Hey all,
>>
>> following on from previous discussions[1], I am introducing an RFC for
>> adding HTTP/2 support to the built-in CLI server:
>>
> On Jan 19, 2016, at 6:21 AM, Derick Rethans wrote:
>
>> On Mon, 18 Jan 2016, Davey Shafik wrote:
>>
>> Hey all,
>>
>> following on from previous discussions[1], I am introducing an RFC for
>> adding HTTP/2 support to the built-in CLI server:
>&g
on it, on newer runtimes.
RFC, with patches, is here: https://wiki.php.net/rfc/php_engine_constant
Thanks,
- Davey
On Wednesday, February 3, 2016, Sara Golemon wrote:
> > I think Dan raises some interesting points, although I think
> zend_version()
> > is often used for feature detection so they try to put a zend version in
> > there to be helpful i.e. HHVM x.y.z === PHP a.b (feature-wise).
> >
> That's exact
HippyVM you're running
on, and to even check that you're using Hippy you need to check for
E_HIPPY_WARN.
We have a chance to standardize, and "mandate" that the information is
exposed explicitly, and done so consistently.
On Wed, Feb 3, 2016 at 5:14 PM, Fred Emmott wrote:
>
&
As an aside, having this kind of #ifdef type stuff also allows us to write
forward compatible scripts without worrying about invalid syntax breaking
older versions.
On Fri, Feb 5, 2016 at 11:20 AM, Pierre Joye wrote:
> On Thu, Feb 4, 2016 at 2:00 AM, Davey Shafik wrote:
> > On
st, then this would be a non-issue.
Unfortunately, changing this behavior would be a — particularly hard to
diagnose — BC break and therefore cannot happen IMO.
Perhaps we could look at an alternative such as:
- traits can implement interfaces, which would ensure the _trait_ adheres
to it, but _not_ automatically classes use'ing it.
- Add a new syntax: "use Trait with Interface" or "use Trait implements
Interface" or "use Trait { implements Interface; }" which *explicitly*
calls out this usage
Just some off-the-top of my head thinking as an alternative.
- Davey
On Fri, Mar 4, 2016 at 2:06 AM, Rowan Collins
wrote:
> Davey Shafik wrote on 04/03/2016 07:17:
>
>> 1. If you simply alias (use foo { bar as bat; }) then you end up with an
>> *additional* method with the new name, the trait method as defined is
>> still
>> b
nullable types. We
already have too many things that are possible in more than one way.
As it sits, this is purely syntactic sugar (when taken in tandem with union
types) and [if] we agree that it is good, then let us just forgo the other
syntax entirely. I'll add a little about that on the appropriate thread.
- Davey
d further expand that with casting rules:
newtype Numeric = int|float {
string as float;
bool as int;
}
or even go so far as:
newtype Numeric = function($value): int|float {
if ($value typeof int) {
return $value;
}
return (float) $value;
}
FTR: I hate that l
$foo[great]" does not evaluate to $foo['my'] but to $foo['great'].
- Davey
On Tue, Apr 12, 2016 at 8:08 PM, Sara Golemon wrote:
> I'm trying to decide just whether or not
> https://bugs.php.net/bug.php?id=71927 is "working as intended" as well
>
t; use float;
> }
>
> Something I would very much like to use where types are allowed.
Could also be used for solving the issue of coercing:
union Numeric {
use int;
use float;
use string as float;
}
Thoughts?
- Davey
I'd interested in co-RMing 7.1 if someone else wants to step up also?
- Davey
On Thu, Apr 21, 2016 at 2:47 AM, Julien Pauli wrote:
> On Tue, Apr 12, 2016 at 10:20 PM, Scott Arciszewski
> wrote:
> > On Tue, Apr 12, 2016 at 2:29 PM, Anatol Belski wrote:
> >>
>
(see:
http://wiki.php.net/rfc/cli_server_http2). Curl also uses libnghttp2 for
it's HTTP/2 support.
I hope to eventually (7.2+) use libnghttp2 to add an ext/nghttp2 HTTP
client and update the HTTP streams layer to support HTTP/2 also.
I'd welcome your collaboration on any of this.
-
On Sat, Apr 23, 2016 at 11:06 AM, Anatol Belski
wrote:
> Hi Davey,
>
> > -Original Message-
> > From: m...@daveyshafik.com [mailto:m...@daveyshafik.com] On Behalf Of Davey
> > Shafik
> > Sent: Friday, April 22, 2016 5:03 AM
> > To: Julien Pauli
>
I seem to have created some confusion here:
The reason _my_ patch for Server Push isn't merged is tests for it were
requested and are blocking it. I'm not saying tests for these constants
should be added.
- Davey
On Wed, Apr 27, 2016 at 4:15 PM, Pierrick Charron wrote:
> Sorry fo
Hey all,
As Joe said, thanks for voting, and we have lots of work ahead of us to
make sure that 7.1 is a solid release — I'll do my best to ensure that
happens!
- Davey
On Tue, May 3, 2016 at 10:01 PM, Joe Watkins wrote:
> Morning internals,
>
> Thanks for voting :)
>
&
g in
null explicitly.
- Davey
On Wed, May 11, 2016 at 12:26 PM, Lester Caine wrote:
> On 10/05/16 21:26, Levi Morrison wrote:
> > It can affect the results.
> >
> > function foo(?Foo $param) {}
> >
> > If any code out there is calling foo with null then that co
like to have |>> for example.
I think that $$ as a positional placeholder gives us the most flexibility.
$$ is super easy to type, apparently is possible with little conflict to
existing syntax, etc.
I'm +1 on |> and $$.
- Davey
On Fri, May 13, 2016 at 2:11 PM, Rasmus Schultz wrote:
> Dear Internals,
>
> I'm announcing a simplified RFC for annotations:
>
> https://wiki.php.net/rfc/simple-annotations
>
> It's an alternative to the proposed Attributes RFC and the (2010)
> Annotations RFC.
>
> I'm attempting with this to de
hen the fact that someone holds a contrary
> opinion is a useful piece of information to the reader, and should stay.
>
> Think of it like a comment section, "the opinions below are not
> necessarily those of the RFC's sponsors".
Perhaps just split it out into a separate document that is concurrent to
the RFC…
- Davey
so "harshly" and as a debate. There
> are
> no "arguments" here, I am simply expressing my own opinion.
>
> As for naming inconsistencies, Rowan addressed that already.
>
> Best regards,
> Benas Seliuginas.
Hi all,
IMO, the onus of proof should be on those wishing to introduce a change
that has a potential conflict, not those trying to prevent one.
I believe that using the PHP namespace is the right way to go, and look
forward to seeing code like this in the future:
>
class Foo { }
- Davey
On Thu, May 7, 2020 at 00:22 Benjamin Eberlei wrote:
> Hi everyone,
>
> The attributes RFC specifically looked into the use of attributes at the
> engine/compiler level.
>
> To have a showcase of this with the 8.0 release I want to propose this RFC
> for a <> attribute:
>
> https://wiki.php.net/r
On Thu, May 7, 2020 at 01:18 Benjamin Eberlei wrote:
>
>
> On Thu, May 7, 2020 at 10:10 AM Davey Shafik wrote:
>
>>
>>
>> On Thu, May 7, 2020 at 00:22 Benjamin Eberlei
>> wrote:
>>
>>> Hi everyone,
>>>
>>> The attributes
as I've been spending my evening working on
HTTP/2 stuff in PHP.
This might be a good time to reopen discussion of adding support for HTTP/2
in PHP with the inclusion of libnghttp2. I posted a long time ago about
adding support for HTTP/2 to the CLI server and the http stream using
libnghttp2 [1].
I think PHP 8.0 would be a perfect opportunity to revisit this given that
HTTP/2 has now reached ~97% adoption[2] and HTTP/3 is on the horizon.
I believe that HTTP/2 has the potential to dramatically change how we serve
content on the web, and PHP should jump on the bandwagon.
- Davey
[1] https://externals.io/message/89932
[2] https://caniuse.com/#search=http%2F2
his->SelectStatement()
}
return $this->syntaxError('SELECT, UPDATE or DELETE');
})($this->lexer->lookahead['type']);
The main selling point for match is that it's more concise, I'm not
convinced that the return if variant is much less concise. If you want to
match more than one thing, use the OR (double pipe) operator in the if
condition.
Having said that… match is undeniably prettier. If we are doing this
however, I'd prefer to implement Go's switch block, named match because we
already have a switch. It's strict, but flexible.
- Davey
extends List { } // this will not work
Given this, I think this specific syntax should be an error, unless I'm
missing something?
Also, does this mean we can alias to fully namespaced names now?
use \My\Foo as \Bar\Foo;
class Bat extends \Bar\Foo { } // now actually extends \My\Foo, not
\Bar\Foo (no autoload would happen?)
- Davey
On Tue, Jun 16, 2020 at 1:34 PM Nikita Popov wrote:
> On Tue, Jun 16, 2020 at 10:28 PM Davey Shafik wrote:
>
>>
>>
>> On Tue, Jun 16, 2020 at 1:52 AM Nikita Popov
>> wrote:
>>
>>> Hi internals,
>>>
>>> Inspired by the recent
1 - 100 of 213 matches
Mail list logo
