Pierre Joye wrote:
> See https://github.com/php/php-src/blob/master/win32/build/libs_version.txtor
> in the respective branch, tag or release.
Thanks a bunch!
--
Ryan McCue
<http://ryanmccue.info/>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
issue), and PHP
internally checks that the file was originally created by the internal
parser. If that's changed, there's probably security concerns with doing so.
+1 on the idea though.
--
Ryan McCue
<http://ryanmccue.info/>
--
PHP Internals - PHP Runtime Development Mailin
> field in the Subject field of the certificate MUST be used. Although
> the use of the Common Name is existing practice, it is deprecated and
> Certification Authorities are encouraged to use the dNSName instead.
--
Ryan McCue
<http://ryanmccue.info/>
--
PHP Internals - PHP Run
hence believe that github.com does not have
a valid certificate.)
I recently had to work around this in userland:
https://github.com/rmccue/Requests/pull/63 and
http://core.trac.wordpress.org/ticket/25007 - which to my knowledge, are
the only HTTP clients in userland that go this far for valid
would
those be T_STRINGs now? I can think of a bunch of userland stuff
(basically every documentation generator) that will break if the
class/function name is not a T_STRING.
That said, +1 for the feature, great idea.
--
Ryan McCue
<http://ryanmccue.info/>
--
PHP Internals - PHP Runtime Develop
although you can map them
if you need to change a key).
All this does is add first-class support in the language.
Huge +1 for this feature and thank you to Nikita for working on the RFC.
--
Ryan McCue
<http://ryanmccue.info/>
--
PHP Internals - PHP Runtime Development Mailin
erm.
That's what I meant by the "backwards compatibility layer". Not saying
we have to deprecate the use as a construct, but why can't we enable the
use as a function (and hence, callback, etc)? It feels less cleaner from
my point of view (userland).
--
Ryan McCue
<http://r
d* performance penalty)
Is there a reason that echo/print couldn't be implemented as functions
with some sort of backwards compatibility layer? isset/etc make sense to
be language constructs, but I can't think of any reason echo/print need
to be.
--
Ryan McCue
<http://ryanmccue.info
I have two HTTP message parsers that I maintain, and neither
of them use goto. Certainly possible to avoid it there.
That said, I do think goto has legitimate uses, even if I don't need it.
--
Ryan McCue
<http://ryanmccue.info/>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ith the other developers.
--
Ryan McCue
<http://ryanmccue.info/>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
t
with 3.5.1 (the latest release)?
(My guess is that it will show WP being slower and with a more dramatic
improvement.)
Thanks,
--
Ryan McCue
<http://ryanmccue.info/>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ou need to
pass in the exact callback that you registered it with; with closures,
this isn't possible unless they're assigned to a variable, which defeats
the purpose.
> Maybe next year it will be time for a GoPHP5.5 project. :-) Hopefully by
> then WP will have become less conser
y static methods.)
This all said, the internal dynamics of the WordPress core developers
are always changing, and views are definitely becoming less
conservative. I don't think you'll see us targeting 5.4 any time soon,
but 5.3 is a possibility. I've been talking to a few
, but it wouldn't
change much of WordPress internally. Anonymous functions, e.g., are
fairly incompatible with the way we implement the Mediator pattern with
our hooking system. Namespaces might be implemented for new code, but
there's basically zero chance for the existing code base.
--
Ryan McCue
<http://ryanmccue.info/>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
x27;ve dealt with this in the past and we'll continue to do so.
--
Ryan McCue
<http://ryanmccue.info/>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
string
> */
>
> Will be : array( 'Route("/")' => "", 'ORM(Key="foo")' => "", "var" =>
> "string" )
What about repeated keys? i.e:
@param int $a
@param string $b
--
Ryan McCue
<http://ryanmccue.info/>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Rasmus Lerdorf wrote:
> On 11/16/2012 01:34 AM, Ryan McCue wrote:
>> Pierre Joye wrote:
>>> Wordpress lead developer statement is rather clear: Go ahead, we will
>>> follow.
>>
>> Indeed, we have patches written already [1], but they were low priority.
>
ttp://core.trac.wordpress.org/ticket/21663
--
Ryan McCue
<http://ryanmccue.info/>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
6%): http://wordpress.org/about/stats/
--
Ryan McCue
<http://ryanmccue.info/>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
while (($key = array_shift($keys)) !== null) {
$array =& $array[$key];
}
return $array;
}
(Not tested. It will fail if the key doesn't exist, you can optionally
check that and fail however you'd like.)
--
Ryan McCue
<http://ryanmccu
t I preferred __CLASS__ as well to be more in
> line with what we currently have, I haven't changed my mind since the
> arguments provided didn't convinced me at all.
I somewhat agree; using __CLASS__ would make it more obvious that it's
compile-time rather than runtime, IMO.
As far as I can tell, there's no standard which uses the Olson database
to specify the timezone, so we'd have to create one.
What about ISO8601 with the Olson timezone suffixed?
2012-09-02T18:17:36+0100 (Europe/London)
2012-09-02T18:19:05+0100 (Africa/Niamey)
--
Ryan M
rson who was confused when we talked about
> generators RFC and thought we meant IETF RFC describing standards for
> electrical generators in data centers.
I meant more with regards to numbered RFCs.
--
Ryan McCue
<http://ryanmccue.info/>
--
PHP Internals - PHP Runtime Development Mai
C on how to write an RFC".
If we do that, we should call them PHP RFCs (PRFCs?) instead, to avoid
confusion with IETF RFCs, otherwise it may get confusing.
--
Ryan McCue
<http://ryanmccue.info/>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ng two commits in the commit history isn't
that bad.
(The main issue I can think of is with using `git blame`)
--
Ryan McCue
<http://ryanmccue.info/>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
byte-level and character-level where
needed, with character-level functions based on mbstring.
--
Ryan McCue
<http://ryanmccue.info/>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
d.
Somewhat off-topic, but is there a reason why not? It seems to me that
introducing a new API without using PHP's best method of error handling
(IMHO) is a little silly.
--
Ryan McCue
<http://ryanmccue.info/>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
', $value => 'abc');
...would be better.
--
Ryan McCue
<http://ryanmccue.info/>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Stas Malyshev wrote:
Basically, it allows you to do this:
create_query("deleted=0", "name",,, /*report_errors*/ true);
I'm a huge fan of this idea, for all the reasons listed on the RFC and
one additional one: it brings normal functions in line with the syntax
for list() - We can skip param
Kris Craig wrote:
An argument could be made that, as the users of PHP, they should be
able to have some say in its development.
As a PHP developer (that is, a developer who writes in PHP), I'd agree,
*to an extent*. There are certainly things that I'd like to be able to
vote on (such as addit
k that is a documentation issue. We already have plenty of
confusion here because it isn't documented that parse_str() is affected
by the max_input_vars setting.
I think that is definitely a documentation issue, but the extra argument
is the way to go in terms of being the least
hat's something we
necessarily want.
--
Ryan McCue
<http://ryanmccue.info/>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
have significant data loss is covered by that.
Bottom line: I'd personally use this, while I certainly would not use
the previous style (with `(int) $foo` e.g.).
--
Ryan McCue
<http://ryanmccue.info/>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ersonally, I don't think PHP's system needs to change any time soon (or
indeed, at all), unless a majority of contributors really want to. It's
just a waste of time and resources otherwise.
--
Ryan McCue
<http://ryanmccue.info/>
--
PHP Internals - PHP Runtime Development Mai
s are much easier to deal with and
should be the way to go here. If you use a single method for all the
casts, you'll probably end up recreating separate methods anyway (i.e.
`case 'int': return $this->toInt();` ) which seems silly to me.
--
Ryan McCue
<http://ryanmccue.info
Ryan McCue wrote:
Double-checking, but this is different to normal typecasting, isn't it?
If so, it might be a bit confusing using the typecasting syntax.
Could have sworn I saw that "123foo" would give E_RECOVERABLE_ERROR, but
I can't find that now, so possibly disre
a bit confusing using the typecasting syntax.
--
Ryan McCue
<http://ryanmccue.info/>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ns are T_OBJECT_OPERATOR and T_DOUBLE_ARROW respectively, if
that helps: http://www.php.net/manual/en/tokens.php
The namespace operator is T_NS_SEPARATOR.
Hope that helps,
--
Ryan McCue
<http://ryanmccue.info/>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
best :-)
I have no need for the class any more, since I'm using a different
documentation tool instead.
--
Ryan McCue
<http://ryanmccue.info/>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Ryan McCue wrote:
> For some purposes, you need to be able to reflect files and classes
> without loading them, which I think is a huge gap in the Reflection API.
> That said, a proper ReflectionFile would be welcome, even if it did load
> the file.
Forgot to mention: it is also, as f
tion
For some purposes, you need to be able to reflect files and classes
without loading them, which I think is a huge gap in the Reflection API.
That said, a proper ReflectionFile would be welcome, even if it did load
the file.
--
Ryan McCue
<http://ryanmccue.info/>
--
PHP Internals - PHP
s go is the one-click
interface on the GitHub site (which I don't like personally, since you
can't test before pushing).
--
Ryan McCue
<http://ryanmccue.info/>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Ferenc Kovacs wrote:
> the aggregated report summaries are available at
> http://qa.php.net/reports/ thanks to Oliver Doucet who make this
> happen.
>
Which, incidentally, doesn't appear to be working at this point in time.
--
Ryan McCue
<http://ryanmccue.info/>
--
PHP
a bottleneck (and I think the
same about strncmp vs. substr; no real need to avoid a temp variable). I
could see this patch being useful, but personally, I think the substr
solution is a better one, since it doesn't risk breaking BC, as Rasmus
noted.
--
Ryan McCue
<http://ryanmccue.inf
while "porcelain" are tools
built on top of that (such as the "commit", "push", "pull", "merge"
commands that people would be familiar with).
--
Ryan McCue
<http://ryanmccue.info/>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
commit*. That means that if an external is
updated, the submodule must be updated, and that change must be committed.
(Forgot to send this to the list as well, gah!)
--
Ryan McCue
<http://ryanmccue.info/>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit
e at least as
good as Hg's Windows tools.
FWIW, I manage a whole bunch of projects on Git from Windows and I've
never had an issue.
(Forgot to send this to the list, again.)
--
Ryan McCue
<http://ryanmccue.info/>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Ferenc Kovacs wrote:
> I would like to introduce this RFC which would provide function
> autoloading through the spl_autoload facility without userland BC
> breakage.
Shouldn't the default type be T_CLASS|T_INTERFACE?
--
Ryan McCue
<http://ryanmccue.info/>
--
PHP Int
goal
should be readability above all.
Having read the other responses on this topic, I have to agree that
there's no need for any short syntax, so -1 on the short syntax from me.
(Forgot to send this to the list; sorry for the duplicate Brian!)
--
Ryan McCue
<http://ryanmccue.info/>
--
PH
sense here and actually makes the readability worse, IMO. However,
I can't really think of a better operator. ( $x ) => $x + 1 for example
would be ambiguous if used in an array definition, but is otherwise the
best in terms of readability.
--
Ryan McCue
<http://ryanmccue.info/>
--
50 matches
Mail list logo