Hi internals.
What do you think about moving the PHP documentation to a Git repository,
mirrored on Github? Doing this would make it possible for everybody to extend
the documentation easily by creating pull requests.
Today one has to get an SVN account to edit the docu or you have to use
Hi,
Another two cents here.
* Skipping binding a parameter to the exception would make debugging
harder. When you're stepping through code that isn't working correctly to
find a problem and then it throws an Exception which is caught in catch
block that doesn't name it e.g.
try
{
On 25.06.2013 08:46, Christian Stoller wrote:
Hi internals.
What do you think about moving the PHP documentation to a Git repository,
mirrored on Github? Doing this would make it possible for everybody to extend
the documentation easily by creating pull requests.
Today one has to get an SVN
On 25/06/13 07:46, Christian Stoller wrote:
What do you think about moving the PHP documentation to a Git repository,
mirrored on Github? Doing this would make it possible for everybody to extend
the documentation easily by creating pull requests.
Today one has to get an SVN account to edit
On Tue, Jun 25, 2013 at 9:45 AM, Christoph Rosse cro...@2bepublished.at wrote:
On 25.06.2013 08:46, Christian Stoller wrote:
Hi internals.
What do you think about moving the PHP documentation to a Git repository,
mirrored on Github? Doing this would make it possible for everybody to
extend
and now with the right name...
On Tue, Jun 25, 2013 at 10:18 AM, Pierre Joye pierre@gmail.com wrote:
On Tue, Jun 25, 2013 at 9:45 AM, Christoph Rosse cro...@2bepublished.at
wrote:
On 25.06.2013 08:46, Christian Stoller wrote:
Hi internals.
What do you think about moving the PHP
On Tue, Jun 25, 2013 at 10:18 AM, Pierre Joye pierre@gmail.com wrote:
On Tue, Jun 25, 2013 at 9:45 AM, Christoph Rosse cro...@2bepublished.at
wrote:
On 25.06.2013 08:46, Christian Stoller wrote:
Hi internals.
What do you think about moving the PHP documentation to a Git
On Tue, 2013-06-25 at 08:46 +0200, Christian Stoller wrote:
Hi internals.
What do you think about moving the PHP documentation to a Git
repository, mirrored on Github? Doing this would make it possible for
everybody to extend the documentation easily by creating pull
requests.
Basically
On Tue, Jun 25, 2013 at 5:10 AM, Johannes Schlüter
johan...@schlueters.dewrote:
On Tue, 2013-06-25 at 08:46 +0200, Christian Stoller wrote:
Hi internals.
What do you think about moving the PHP documentation to a Git
repository, mirrored on Github? Doing this would make it possible for
Hi everyone,
I've got an idea for an RFC proposal and from reading the instructions it
looks like I should run it past you guys first.
I have not made any contributions to PHP before although I have made some
custom modifications in house in the past and while I'm no longer familiar
with the PHP
On 06/25/2013 11:10 AM, Johannes Schlüter wrote:
That aside: resources is also the issue with the online editor. We have
too few people working on docs, so in the end it doesn't make much
difference if they don't have time to review edit.php.net or github.
(while reviewing on edit.php.net has
That aside: resources is also the issue with the online editor. We have
too few people working on docs, so in the end it doesn't make much
difference if they don't have time to review edit.php.net or github.
(while reviewing on edit.php.net has the benefit that it can directly
validate the
Hi all,
I just published an RFC that proposes to add catch-statement without needing
to specify a variable, and support for fully anonymous catches.
Details can be found at:
https://wiki.php.net/rfc/anonymous_catch
Regards,
Joost Koehoorn
Hi.
I am not sure about
I, too, believes that omitting the exception variable is great.
In addition, anonymous catch blocks will shorten the code of catch
(Exception $e) so... is just a simpler way of writing - and that's what
PHP agenda aiming for, doesn't it? be a friendly and readable language.
Reading
try {
Hi all,
I'm having trouble to utilize DNS RoundRobin. It's described in
StackOverflow question:
http://stackoverflow.com/questions/17209912/php-not-respecting-roundrobin-in-dns
In short: file_get_contents, SOAP extension always connect to the first
(lowest) IP address, and gethostbyname
On Tue, Jun 25, 2013 at 12:54 AM, Joost Koehoorn
joost.koeho...@gmail.com wrote:
Hi all,
I just published an RFC that proposes to add catch-statement without needing
to specify a variable, and support for fully anonymous catches.
Details can be found at:
On Tue, Jun 25, 2013 at 12:54 AM, Joost Koehoorn
joost.koeho...@gmail.com wrote:
Hi all,
I just published an RFC that proposes to add catch-statement without needing
to specify a variable, and support for fully anonymous catches.
Details can be found at:
Hi,
Just my two cent.
The online editor is actually a greats tool to edit commit some changes
into the documentation for *all* translations. Please, don't view only the
EN part of the documentation.
If we plan to move to GitHub, there were a lot of work to do into the
editor to continue to use
On Tue, Jun 25, 2013 at 12:54 AM, Joost Koehoorn
joost.koeho...@gmail.comwrote:
Hi all,
I just published an RFC that proposes to add catch-statement without
needing to specify a variable, and support for fully anonymous catches.
Details can be found at:
Hey all,
I want to throw out this draft RFC to get the concept floating around and
get feedback early.
https://wiki.php.net/rfc/protocol_type_hinting
There are still open questions, and a more complete (and cleaner)
implementation will be needed before officially proposing it, but I wanted
to
On 2013-06-25, Ferenc Kovacs tyr...@gmail.com wrote:
there were some initial discussion and work done on moving the docs to git,
see
https://wiki.php.net/doc/git
http://git.php.net/?p=3Dweb/doc-editor.git;a=3Dshortlog;h=3Drefs/heads/GIT_=
READY
On Tue, 25 Jun 2013 19:57:15 +0400, Anthony Ferrara ircmax...@gmail.com
wrote:
Hey all,
I want to throw out this draft RFC to get the concept floating around and
get feedback early.
https://wiki.php.net/rfc/protocol_type_hinting
There are still open questions, and a more complete (and
Nikita,
Thanks for the response!
By looking at the diff I see it will only work for type-hints in
functions/methods. Could we also see something like $var instanceof
ProtoInterface? I fear it can't be done this way because of parser
limitations, but I believe this feature would be as useful
On Tue, Jun 25, 2013 at 1:05 PM, David Soria Parra d...@php.net wrote:
On 2013-06-25, Ferenc Kovacs tyr...@gmail.com wrote:
there were some initial discussion and work done on moving the docs to
git,
see
https://wiki.php.net/doc/git
On Tue, Jun 25, 2013 at 11:57 PM, Anthony Ferrara ircmax...@gmail.com wrote:
Hey all,
I want to throw out this draft RFC to get the concept floating around and
get feedback early.
https://wiki.php.net/rfc/protocol_type_hinting
There are still open questions, and a more complete (and
On 25 June 2013 18:32, Laruence larue...@php.net wrote:
On Tue, Jun 25, 2013 at 11:57 PM, Anthony Ferrara ircmax...@gmail.com wrote:
Hey all,
https://wiki.php.net/rfc/protocol_type_hinting
What do you think?
Hey:
Just one question, usage? why we need this? (run-time check is
slow and
On Tue, Jun 25, 2013 at 12:45 AM, Christoph Rosse
cro...@2bepublished.at wrote:
On 25.06.2013 08:46, Christian Stoller wrote:
Hi internals.
What do you think about moving the PHP documentation to a Git repository,
mirrored on Github? Doing this would make it possible for everybody to
extend
Hi!
In such a case you do not need any `$e`variable. Netbeans for example
always highlight's these variables because it is not used anywhere.
But I think it looks a bit cleaner if the variable could be omitted,
if it's not needed ;-)
I don't think we need to change the language because
Anthony,
I like it. The one thing that is lacking in the PHP ecosystem is some
kind of support for a Gentleman's Agreement when it comes to APIs. I
am very much opposed to central bodies of code and/or shared interfaces
(like the PSR-3's et. al.) for seemingly simple and cross-cutting APIs.
On 25 June 2013 20:17, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
I don't think we need to change the language because Netbeans can't
figure out how catch blocks work. This change doesn't provide any
functionality that wasn't available before it, and does not make the
code clearer - on
On 25 June 2013 17:07, Nikita Popov nikita@gmail.com wrote:
No opinion on leaving off $e, but I'm against the generic catch{} statement.
I second the concerns about empty catch{}.
--
Regards,
Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
On 25 June 2013 17:07, Nikita Popov nikita@gmail.com wrote:
No opinion on leaving off $e, but I'm against the generic catch{} statement.
I second the concerns about empty catch{}.
--
Regards,
Mike
As most of you seem to discard the idea about and empty catch (I can see why,
no
On 6/25/13 10:57 AM, Anthony Ferrara wrote:
Hey all,
I want to throw out this draft RFC to get the concept floating around and
get feedback early.
https://wiki.php.net/rfc/**protocol_type_hintinghttps://wiki.php.net/rfc/protocol_type_hinting
There are still open questions, and a more
Hi!
IMO actually it *makes* the code clearer, because $ignoredException is
not used, though a variable name like $ignored is self-explanatory,
too.
It's not used by you - which btw is usually not a good idea - if you've
got an exception, you usually should somehow react to it - at least log
Regarding all of the discussion about the unused variable:
If your catch blocks are too long or too complicated to be able to tell
that the variable is unused, then I highly suggest you refactor that
section.
---
To me, the only maybe-useful portion of this discussion would be the empty
catch
On Tue, Jun 25, 2013 at 3:50 PM, Stas Malyshev smalys...@sugarcrm.comwrote:
Hi!
IMO actually it *makes* the code clearer, because $ignoredException is
not used, though a variable name like $ignored is self-explanatory,
too.
It's not used by you - which btw is usually not a good idea -
On 25 juni 2013 at 22:06:40, Sherif Ramadan (theanomaly...@gmail.com) wrote:
On Tue, Jun 25, 2013 at 3:50 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
IMO actually it *makes* the code clearer, because $ignoredException is
not used, though a variable name like $ignored is
Hi!
Hey all,
I want to throw out this draft RFC to get the concept floating around and
get feedback early.
https://wiki.php.net/rfc/protocol_type_hinting
I'm not sure I understand why it is good to have this. This way of
checking interfaces is very expensive (since you need to scan the
Hi!
If I'm to understand this RFC correctly, it is nothing more than a
random suggestion someone posed in the form of a tweet and the author is
saying why not add it since it's not hard to implement. So in summation
Well, here we go - this is why not add it, because it makes working with
such
On Tue, 2013-06-25 at 13:19 -0700, Stas Malyshev wrote:
Hi!
If I'm to understand this RFC correctly, it is nothing more than a
random suggestion someone posed in the form of a tweet and the author is
saying why not add it since it's not hard to implement. So in summation
Well, here we
Laruence,
Hey:
Just one question, usage? why we need this? (run-time check is
slow and I can not think out of a case then we must need it)
In practice, the run-time check shouldn't be that slow. In fact, I just did
a quick micro-benchark without actually implementing caching, and it's
Stas,
I'm not sure I understand why it is good to have this. This way of
checking interfaces is very expensive (since you need to scan the
function table) and relies on function names instead of explicit
programmer's intent to validate the API (i.e. it assumes if two classes
have method
Hi!
This may sound trivial, but imagine this. Right now Zend and Symfony have
very similar providers for certain tasks. One of the ones that comes to
mind (besides logging) is caching. If you want to use a Zend component in
an Symfony app while still using caching today, you'd need to shim
On Wed, Jun 26, 2013 at 1:16 AM, Stas Malyshev smalys...@sugarcrm.comwrote:
Hi!
This may sound trivial, but imagine this. Right now Zend and Symfony have
very similar providers for certain tasks. One of the ones that comes to
mind (besides logging) is caching. If you want to use a Zend
Hi!
See my reply to Laruence, it's not more expensive...
I don't see how you can see it's not - it does method matching on every
call. It just doesn't make sense that doing something N times is faster
than doing something 1 time. That may be true only if you load classes
you don't ever need (no
Stas,
On Tue, Jun 25, 2013 at 6:16 PM, Stas Malyshev smalys...@sugarcrm.comwrote:
Hi!
This may sound trivial, but imagine this. Right now Zend and Symfony have
very similar providers for certain tasks. One of the ones that comes to
mind (besides logging) is caching. If you want to use a
Hi all,
Current pgsql module lacks direct binary support. Therefore, users have to
use pg_escape_bytea/pg_unescape_bytea for binary handling even with
prepared statement type APIs. Use of
pg_escape_bytea/pg_unescape_bytea requires some overheads on both server
and client side.
Following patch
Hi,
On Tue, Jun 25, 2013 at 11:54 PM, Anthony Ferrara ircmax...@gmail.com wrote:
Laruence,
Hey:
Just one question, usage? why we need this? (run-time check is
slow and I can not think out of a case then we must need it)
1. Library implementers don't need to declare a dependency for a
Hi!
Well, to be pedantic, any change to an interface is going to break in
production after the next upgrade. No matter what you're doing. Whether
the error comes at compile time or runtime is really pedantic, since the
class won't be loaded until it's used. So you may not hit it at compile
Stas,
I don't see how you can see it's not - it does method matching on every
call. It just doesn't make sense that doing something N times is faster
than doing something 1 time. That may be true only if you load classes
you don't ever need (no autoloader? why?) - but even in this case your
IMO GO like interfaces become handy in the following situation:
Library A wants that you pass a class at some point (let's say a logger)
which implements interface ALogger (as defined by lib A)
Library B wants that you pass a class at some point which implements
interface BLogger
Both
51 matches
Mail list logo
