Re: [PHP-DEV] 7.0.0 release
On Mon, Nov 23, 2015 at 10:10 PM, Anatol Belski <weltl...@outlook.de> wrote: > > a) release on 26th including all known bug fixes > b) do RC8, assume there are no bugs, so target 10th for RTM > c) do RC8, release on 3rd, expect there are no bugs come in > d) continue issuing release candidates till it's stable enough (needs > definition of stable and probably an RFC) > C would be ideal. Give everyone a chance to validate the count fix, plus its a nice date that does not leave Americans up in arms about turkeys and its way before christmas, very neutral ground -- Rafael Dohms PHP Evangelist and Community Leader http://doh.ms http://www.amsterdamphp.nl <http://wwwamsterdamphp.nl>
Re: [PHP-DEV] INDRECT in arrays causes count() to become unpredictable
On Sun, Nov 22, 2015 at 11:19 PM, Rasmus Lerdorf <ras...@lerdorf.com> wrote: > Let's get 7.0.0 out the door and get ourselves on > track for regular point releases without any of this "perfect-release" > stress. > > -Rasmus > > Can I just bring us back to a week ago when we spent a couple days discussing the "new" release date? There was a big push to avoid 26th due to Thanksgiving and some people went as far as christmas. I see here a great opportunity to delay for a good valid reason, and at the same time solve the "clashing" date problem. And I agree with Anthony, if we found a serious bug, let's fix it, its not about perfect releases its about ignoring known issues. -- Rafael Dohms PHP Evangelist and Community Leader http://doh.ms http://www.amsterdamphp.nl <http://wwwamsterdamphp.nl>
Re: [PHP-DEV] [VOTE] Reserve even more type hints
This vote was supposed to end on 29/3 but it seems to still be open. Can someone with proper access finish it?
Re: [PHP-DEV] [RFC] [INFO] Basic Scalar Types
I asked whether there was anything in the Voting RFC (wiki.php.net/rfc/voting) or the Timeline RFC (wiki.php.net/rfc/php7timeline), the two RFCs being used to block a Basic STH poll from going to a vote for PHP 7.0, that somehow make it legitimate for it to be proposed if the Dual Mode RFC fails. The answer - there's not. I may be missing something, but isn't the reason why its not going up for vote that it has not gone through the RFC process yet? 2 weeks here, 2 weeks there and such? Honest question, please don't take it off-tone. -- Rafael Dohms PHP Evangelist and Community Leader http://doh.ms http://www.amsterdamphp.nl http://wwwamsterdamphp.nl
Re: [PHP-DEV] [RFC][Status] Scalar Type Declarations Voting Date Change
FWIW, regardless of the politics and finger pointing here. I think the only sane way to start solving this is what Anthony has proposed. Set a *fair* closing date, with plenty time for both sides to react as they wish and let the chips fall where they may. Its not about Zeev or Anthony or anything else. Its about closure and moving on. Let's all stop accusing everyone and focus on reading RFCs and voting. -- Rafael Dohms PHP Evangelist and Community Leader http://doh.ms http://www.amsterdamphp.nl http://wwwamsterdamphp.nl
Re: [PHP-DEV] Re: Annotations in PHP7
On Mon, Feb 16, 2015 at 7:41 PM, Dmitry Stogov dmi...@zend.com wrote: this won't implement features necessary for phpDocumentor, Doctrine, etc. Just be careful here with phpDocumentor, it does not use annotations but really needs docblocks instead. Today the overlap between it and doctrine and such is just matching syntax, but it for example does not support parametrized annotations. So let's just stick to Doctrine and other annotation specific libs for reference of userland implementations. -- Rafael Dohms PHP Evangelist and Community Leader http://doh.ms http://www.amsterdamphp.nl http://wwwamsterdamphp.nl
Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution
On Fri, Mar 8, 2013 at 6:55 AM, Andi Gutmans a...@zend.com wrote: The 62.8% comparison to 60.7% is the most out of touch thing I've read on this mailing list in a long time. If you're talking about pure feature yay/nay then 94% have given a yay to this feature. The split is the timing. Sorry, but math is not liable to what is being measured by a percentage. So to this point if there is something being done without 2/3 approval, then its wrong. Does not matter what it is, who is proposing and who likes it or not. And as far as timing is concerned I do not see how this whole thing falls into the 2/3 vote for new language syntax/prevent feature creep rule. Many times in the past have we aligned new PHP versions with runtime improvements esp. as they are often exciting and beneficial to most of our audience. I don't see why we wouldn't do that given that the cost is pretty minimal and the benefit to our audience is high. I'm sorry, but Anthony's example is spot on for this. Property accessors matter a lot to me and will benefit all frameworks and people who use them there was no special treatment there and there should be no special treatment here. I'm right now oblivious to what is being voted or not in this case, but ignoring a defined 2/3 rule is clearly wrong. Either remove rules or follow them otherwise they become useless noise. -- Rafael Dohms PHP Evangelist and Community Leader http://doh.ms http://wwwamsterdamphp.nl
Re: [PHP-DEV] Was Reflection annotations reader - We Need A Vision
On Thu, Jan 10, 2013 at 2:39 AM, Adam Harvey ahar...@php.net wrote: So my dilemma is this: how do I voice this (without simply a drive-by -1 vote, which isn't really helpful either, and is overly discouraging to the people who've put a lot of work in to polish the feature up) without being shouted down for being unhelpful or uncivil? In my humble opinion, if your only argument is a -1, the don't be part of the discussion, but rather be a vote when (and if) the RFC goes to a vote. There are 2 moments to express yourself: the discussion, the vote. In the discussion phase I believe opinion should be expressed with solid concerns. Performance issues, bad syntax, is it relevant or not, etc. A simple i don't like it does not add, so it can be ommited. The voting is where you can simply say: i don't want this regardless of the syntax intent or how many unicorns it provides. That is what i do. -- Rafael Dohms PHP Evangelist and Community Leader http://doh.ms http://wwwamsterdamphp.nl
Re: [PHP-DEV] - True Annotations
On Wed, Jan 9, 2013 at 5:20 PM, Larry Garfield la...@garfieldtech.comwrote:
On 1/9/13 9:31 AM, Levi Morrison wrote:
they are nearly syntactically identical to executable code.
nearly is the keyword there. They lack the ending semi-colon. Sure,
this might mean PHP has to actually use an abstract syntax tree, but
that's long overdue in my opinion. I know others disagree. This is
only tangentially related, so I won't say more.
Even if the parser is adjusted to cope with that, it's still an extremely
subtle difference for developers to keep track of. Consider the following
procedural snippets:
@Foo[narf]
function something($narf) {}
@Foo[narf];
function something($narf) {}
The first one says that $narf should pass @Foo validation.
The second one says to call the function Foo with the string constant
narf, and then define a function called something().
That's the sort of subtle bug that's just begging for someone to make an
honest typo and spend the next 6 hours tracking it down, until he realizes
what he did and proceeds to bang his head against his desk in frustration
for missing such a simple error.
Let's not subsidize the headache drug manufacturers with PHP syntax
decisions. :-)
--Larry Garfield
I agree with the risks here.
But i also really prefer a Token: content approach then a [open token]
content [close token] approach
Can we use a combination? like:
@annot: Foo[narf]
--
Rafael Dohms
PHP Evangelist and Community Leader
http://doh.ms
http://wwwamsterdamphp.nl
Re: [PHP-DEV] [RFC] Reflection annotations reader
I agree with Rasmus on this one.
Userland solutions are enough to support a in-docblock solution today, the
performance gains from making it SPL are too little to matter.
However docblocks are a compromise, and not where these should be.
I do suggest we revive Guilherme's RFC and try once more to arrive at a
acceptable syntax. A lot has happened since the last discussion, maybe
this time the usefulness of annotations can be further moved along and we
can get this patch into core.
That would be: https://wiki.php.net/rfc/annotations
Maybe moving more towards the implementation described by Rasmus Schultz.
On Tue, Jan 8, 2013 at 4:42 AM, guilhermebla...@gmail.com
guilhermebla...@gmail.com wrote:
Cof... cof...
https://wiki.php.net/rfc/annotations
Good luck convincing php-src folks.
You'd be my hero.
On Mon, Jan 7, 2013 at 9:50 PM, Rasmus Schultz ras...@mindplay.dk wrote:
On parsing annotations in docblocks: please don't.
First of all, there are already plenty of established userland
implementations - so there is really no need for this.
Whatever you decide on in terms of syntax, most likely won't satisfy
every
the needs of every userland annotation library, so at least some of them
most likely won't use it. You'd be creating more work for the maintainers
of these frameworks, and they don't standard to gain anything from that
work.
In terms of performance, there is nothing significant to gain here - any
good annotation engine/framework already caches parsed annotations.
On the other hand, I would be interested in having support for actual
annotation syntax (not docblocks) added to PHP. Real annotation syntax
could have benefits over parsing docblocks, starting with the fact that
most of what's currently in docblocks is documentation, and thus not very
interesting at run-time for anything other than documentation generators.
(again, documentation generators already have working parsers, and don't
stand to gain anything significant from switching to a native docblock
parser.) - also mind the fact that docblocks are a loose standard with
many
more variations since annotation libraries came around.
The only real downside (in terms of run-time) to adding custom syntax, is
that existing useful annotations (such as @var for property-types) would
not be useful - but in another sense, that's a good thing, because (for
the
most part) in existing codebases, these were written as documentation,
not
intended for run-time consumption. IDEs and documentation tools can add
support for new annotation syntax, and treat these consistently and
code,
which itself can be documented using phpdoc blocks.
I would support and encourage a C# style syntax and behavior, e.g.:
use my\lib\DataType;
[DataType('datetime')]
public $published_date;
In other words, DataType is a class, implementing an interface for
initialization - everything between the parentheses is interpreted
basically the same way as in an array() statement, and is passed to the
annotation instance after construction via an initialization method
defined
by the interface.
I could elaborate tons more on this subject, as it's something I have
spent
a lot of time researching in different languages, prior to writing my own
annotation library.
It may strike you as odd that someone who implemented an annotation
library
based on docblocks is actually against annotations in docblocks - I
mainly
chose that option because it was the best option at the time. I'm not a C
programmer, and I do believe that docblocks are the best approach for a
native PHP implementation. For a native implementation, I'd prefer to
see a
clear separation between non-functional documentation metadata and
functional annotation objects. While there is some overlap between the
two,
much of what is currently written as documentation (for example @var
annotations) could be written as functional annotations when these have a
meaningful purpose. After all, existing code with phpdoc-annotations most
likely was not written with the intent of consuming that metadata at
runtime, unless written for use with an annotation library.
I would be happy to involve myself deeper in this, if others agree and
would like to work on a new RFC.
- Rasmus Schultz
--
Guilherme Blanco
MSN: guilhermebla...@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
--
Rafael Dohms
PHP Evangelist and Community Leader
http://doh.ms
http://wwwamsterdamphp.nl
Re: [PHP-DEV] [RFC] Reflection annotations reader
On Tue, Jan 8, 2013 at 11:05 AM, Pierre Joye pierre@gmail.com wrote: On Tue, Jan 8, 2013 at 10:57 AM, Derick Rethans der...@php.net wrote: This belongs in an extension, just like last time we've discussed annotations. Last time we discussed this area, we discussed almost everything about docblock and the likes but actual annotation. However I do not get your reasoning, annotations are part of languages features, how could it fit in an extension? That makes no sense. I also agree it is core due to its nature. But also, given the large amount of frameworks that support the use of annotations and the nature of hosting providers and extensions, I really think this is a core feature. -- Rafael Dohms PHP Evangelist and Community Leader http://doh.ms http://wwwamsterdamphp.nl
Re: [PHP-DEV] [RFC] Reflection annotations reader
On Tue, Jan 8, 2013 at 10:37 PM, Stas Malyshev smalys...@sugarcrm.comwrote: Hi! Everyone I talked to who implemented annotations in docblocks did it as hack because there is no native support. This is not something that belongs to docblocks. It would be nice if you could take a look at the c# doc, there are really good concepts there. I know why they did it, and we already discussed that stuff in the last annotation discussion. What I mean here is that presenting it as if the notion of meaningful comments is completely unheard of in PHP and nobody expects it is just wrong. Maybe it was so years ago, but it is definitely not true now - de-facto meaningful comments *are* the standard now, and have a lot of use, and nobody with any experience is surprised by them. Regardless of *why* is it so, it is a fact. Stas, That still does not make it the right place. Annotations went into docblocks because it was the only place reflection could provide the needed information at runtime. Just because we now treat docblocks as 1st class citizens does not mean annotations should be there. Does that mean that annotations should be in docblocks and not in core for the reason of we all know docblocks exist. I would seriously expect at the very least a stronger reason. These were some of the ones i heard before: 1. The syntax is crap: this is solvable, let's find the right syntax 2. PHP does not need it: i think we have proven the use already, every major FW has a implementation of this, there is clearly demand. So if we are going to get anywhere with this discussion I suggest getting back to the original RFC and working on solving the issues instead of discussing developer folklore. -- Rafael Dohms PHP Evangelist and Community Leader http://doh.ms http://wwwamsterdamphp.nl
[PHP-DEV] SplDoublyLinkedList missing insertBefore/After
I have just noticed that the current SPL inplementation of a DoublyLinkedList does not include methods to insert nodes into the middle of the list (insertBefore, insertAfter). After mentioning it I ran into a few people and other outbursts on the internet of more people who saw this and complained about it. I found a bug from 2009 (https://bugs.php.net/bug.php?id=48358) which mentions the case and has no Core response at all. I ask two questions: 1) Why was this bug never replied to, is there some reason these methods should not be implemented? 2) Is anyone willing to put up a patch for this? I imagine that if you are familiar with C and PHP source this is a quick implementation as its standard logic documented everywhere. I'm not familiar enough with the PHP source to do this myself, hence I'm asking for anyone willing to champion the patch. Thanks! -- Rafael Dohms PHP Evangelist and Community Leader http://www.rafaeldohms.com.br http://www.amsterdamphp.nl
Re: [PHP-DEV] Implicit isset in ternary operator
On Mon, Jul 23, 2012 at 6:19 AM, Alex Aulbach alex.aulb...@gmail.comwrote: 2012/7/23 Sanford Whiteman swhitemanlistens-softw...@cypressintegrated.com: I think that you can compare the situation to the short if syntax ($a $b ? $c : $d) Not sure I understand... that *is* the situation under discussion, no? Use functions. Above case for example: ... My suggestion just is: At any point everybody needs one more operator for his stuff. But that's why functions exists. This is not about his stuff, this is about the general userland expectation of what a ternary operator will do with a $array[key] where it is not set. This is a valid use case in every app and as we saw in lots of frameworks. As for functions, i do not like the idea of having functions around for this kind of operation, it will bring about the return of utils.php and i don't think that's worth. So while i agree not everything needs a core implementation, this does not fall under that case. -- Alex Aulbach -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Rafael Dohms PHP Evangelist and Community Leader http://www.rafaeldohms.com.br http://www.phpsp.org.br
Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
On Fri, Jul 20, 2012 at 10:33 AM, Lester Caine les...@lsces.co.uk wrote: And still seems to be the best way even to 'investigate' this? I still have not had any explanation of what is wrong with ArrayObject? Certainly any changes need to be mirrored identically in that anyway? Also perhaps I am just too set in my ways, but while I understand the needle/haystack complaint, I don't see a major problem that needs everything changing. Perhaps add the odd alternative as that would be the only BC fix anyway? Most of the people who complain about these things are not going to change TO PHP anyway so why keep messing things up for those of us who's livelihood depends on productivity in PHP! I don't see this as solving a major problem, sure most of us relies on IDE's or shear memory to know where needle/haystack should be. But that does not invalidate that this feature is a nice syntax sugar, just like short arrays and other things were. Also this does not have to affect anyone's livelihood or productivity, it will fuel who wants to use it, and maybe the new generation of PHP devs. I for sure would change from using most string functions to it, but not 100% of the time, so really face this as being syntax sugar, which i love, i'm very much focused on code readability and this makes a lot of sense from context and ease of understanding, it does not change everything, but its a nice to have. Technologies and languages evolve, i think its valid to look a new resources to give people more choices and it goes a long way into making learning PHP easier for new devs who don't have to suffer our organic api, which feels confortable for us who have been at it for over 10 years, but is enough of a bother to new people I guess. Anyway, i would love to see this as a alternative, not a replacement, for some of the string functions and similar things -- Rafael Dohms PHP Evangelist and Community Leader http://www.rafaeldohms.com.br http://www.phpsp.org.br
Re: [PHP-DEV] Make try/catch brackets optinal
On Fri, Jul 20, 2012 at 3:51 PM, Léo Peltier cont...@leo-peltier.fr wrote: Enforcing coding style should be forbidden. Clearly you don't work in a team or contribute to Open Source projects. That's what coding styles are for, keeping code looking the same to make readability easier for not-you developers. -- Rafael Dohms PHP Evangelist and Community Leader http://www.rafaeldohms.com.br http://www.phpsp.org.br
Re: [PHP-DEV] Make try/catch brackets optinal
On Thu, Jul 19, 2012 at 11:44 AM, Ivan Enderlin @ Hoa
ivan.ender...@hoa-project.net wrote:
Hi internals,
As you certainly know, brackets defining blocks in PHP are optional if
blocks contain a single instruction. Thus:
if($condition) {
echo 'foobar';
}
is strictly equivalent to:
if($condition)
echo 'foobar';
But this syntactic sugar is not applied uniformly to all PHP language
constructions. I have the try/catch couple in mind.
Writing if blocks without brakets is considered a bad practice. IMHO anyway.
First, I would like to know why it is not possible to write:
try
throw new Exception('foobar');
catch(Exception $e)
var_dump($e-getMessage());
This has code readability problem written all over it. When maintaining it
also has problems, like with the bracket-less if's.
You would need to add brackets if you add an extra line here, as well as
you might get unexpected behaviour of you forget to
add brackets in that case.
as a strict equivalence of:
try {
throw new Exception('foobar');
}
catch(Exception $e) {
var_dump($e-getMessage());
}
Second, if it is possible, could we plan to have this “feature”
(uniformity actually) in PHP6 (or maybe before)?
Sorry, -1 from me.
Re: [PHP-DEV] Make try/catch brackets optinal
On Thu, Jul 19, 2012 at 11:58 AM, Charlie Somerville
char...@charliesomerville.com wrote:
On Thursday, 19 July 2012 at 7:49 PM, Paul Dragoonis wrote:
Why is your try block only going to contain 1 line, and that's
throwing an exception??
try
throw new Exception('foobar');
catch(Exception $e)
Because it's a contrived example. He's not trying to write real code, he's
trying to demonstrate his point - and you totally missed that point.
In this case the removal of brackets would surely limit this to one line,
so any examples or use cases would look the same.
Braces are a good thing, they give structure and stop people from
mis-reading things and writing bugs, the same can be said for the if()
situation.
1) Braces are good.
This is subjective. There are some cases where it might improve code
readability to drop the braces for a single-statement try/catch.
It would cause code maintainability problems and unexpected outputs in
error cases, just like if's do.
There's certainly no technical barrier to doing this. I'm not familiar
with PHP's parser, but I'd imagine there would be some kind of 'statement'
non-terminal that would handle single statements as well as a braced group
of statements.
2) Try with only one line in it to throw an exception doesn't seem
like a realistic situation.
There could be some utility to this. For example, as well as having
post-fix if, unless, etc., Ruby also has a post-fix 'rescue'. Here's a
silly example of its use:
some_var = foo.bar rescue oops
If 'foo.bar' threw an exception, some_var would contain oops instead.
a rescue method is a complete other thing, sounds interesting, but has no
reference to bracket-less try blocks.
I think PHP could benefit from having a single statement try form. I often
turn to PHP for quick and dirty scripts when I need to do something with
little fuss. I think having try/catch support brace-less single statements
would help increase consistency in PHP's syntax, as well as be useful in
certain situations.
I think bracket-less is a bad practice that was left for BC, i would rather
we move away from it then move more things into it.
--
Rafael Dohms
PHP Evangelist and Community Leader
http://www.rafaeldohms.com.br
http://www.phpsp.org.br
Re: [PHP-DEV] Make try/catch brackets optinal
On Thu, Jul 19, 2012 at 12:03 PM, Charlie Somerville char...@charliesomerville.com wrote: This has code readability problem written all over it. When maintaining it also has problems, like with the bracket-less if's. You would need to add brackets if you add an extra line here, as well as you might get unexpected behaviour of you forget to add brackets in that case. I've often heard people make this argument, but I've never found it to be a real concern in practise. Is this really such a common problem? I have seen this problem happen, people losing time trying to figure out what is wrong only to find its a missing bracket. As Paul said, this is bug-prone. -- Rafael Dohms PHP Evangelist and Community Leader http://www.rafaeldohms.com.br http://www.phpsp.org.br
[PHP-DEV] Implicit isset in ternary operator
Hey Everyone, With the syntax improvements for 5.4 and some of the de-referencing work, code looks so much sleeker then before, but there is still one use case that really bugs me. Given this code: $width = (isset($config['width']))? $config['width'] : 300; The code is pretty straight forward, if width is set in the array, use it otherwise use 300. This code would look much better if it could make use of the ternary operator $width = $config['width'] ?: 300; The only reason for this to not work is: it throws a notice if the array key is not there (which is the case we are covering anyway) This is basically because the ternary operator does not do a internal implicit isset, only an empty. Does this seem like a possible improvement we can work on? Anyone interested in championing the change? -- Rafael Dohms PHP Evangelist and Community Leader http://www.rafaeldohms.com.br http://www.phpsp.org.br
Re: [PHP-DEV] Implicit isset in ternary operator
On Wed, Jul 18, 2012 at 4:20 PM, Anthony Ferrara ircmax...@gmail.comwrote: Does this seem like a possible improvement we can work on? Anyone interested in championing the change? I like it in principle. My only concern is *why* wasn't it done this way in the first place... Is there a reason? I don't recall correctly, there was a thread on this by David Coalier some time ago, but it went completely off course and i remember BC breaks were part of the reason. I think we have a good plan for BC breaks now, so why not rethink this. Anthony -- Rafael Dohms PHP Evangelist and Community Leader http://www.rafaeldohms.com.br http://www.phpsp.org.br
Re: [PHP-DEV] [VOTE] Vote change for empty() RFC
Awesome, that clear is up pretty well. I just wanted to get this well cleared up, and since this vote ad its various quirks, why not just sort out all issues once and for all. Thanks for the replies. -- Rafael Dohms PHP Evangelist and Community Leader http://www.rafaeldohms.com.br http://www.phpsp.org.br -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Vote change for empty() RFC
On Mon, May 21, 2012 at 10:36 PM, Lars Strojny l...@strojny.net wrote: Hi Rafael, hope it’s ok I've reopened the vote temporarily, but you’ve got the missing vote. Even better, get this on clean papers. thanks. But i would still like Pierre and others involved with voting to clear up the point about rounding up or down. -- Rafael Dohms PHP Evangelist and Community Leader http://www.rafaeldohms.com.br http://www.phpsp.org.br -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Vote change for empty() RFC
On Mon, May 21, 2012 at 11:25 PM, Gustavo Lopes glo...@nebm.ist.utl.pt wrote: There is nothing unclear about a 2/3 majority is required. 2/3 of all the votes need not be a integer, but that doesn't mean you can't compare it to an integer. If this still doesn't answer your question, please refer to how this works in virtually every election in the world. So we are counting half people now, good i hear Tyrion the Imp going around internals, good. But great that is an answer, an edgy one with unneeded aggressiveness in my opinion, but i guess someone had to ask and deal with the attitude. I'll just step away again. -- Rafael Dohms PHP Evangelist and Community Leader http://www.rafaeldohms.com.br http://www.phpsp.org.br -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [VOTE] Vote change for empty() RFC
On Mon, May 14, 2012 at 1:16 PM, Anthony Ferrara ircmax...@gmail.com wrote: I had meant to reply to the list, but I had replied to Stas directly. I would be happy to change my vote from isset() and empty() to empty() only if that's what it would take... Anthony This would settle it, so in the realm of action what can we do now? Is there a rule that allows to call for a re-vote? Should start a new RFC? Or can we just alter the vote and consider this the end of voting? Sorry, but all this talking is running around in circles, and everything has been said. I would like to bring closure to this topic. -- Rafael Dohms PHP Evangelist and Community Leader http://www.rafaeldohms.com.br http://www.phpsp.org.br -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [VOTE] Vote change for empty() RFC
On Mon, May 21, 2012 at 12:44 AM, Pierre Joye pierre@gmail.com wrote: See the previous mails, as long as other voters agree to change their votes to empty only, we are done. If my math does not fail me, we needed one more vote to have the 2/3 mentioned. Anthony has changed his vote, i think we are good to go. 20 votes = 2/3 = 13.3 So if we round down, the vote originally passed, and in any case Anthony makes it 14, so that should resolve any doubts Also, for future votes we need to make this rule clear: does 13.3 mean we need 13 votes or 14 votes to pass? In which case, this whole thread might actually have been for nothing since the vote had already passed. -- Rafael Dohms PHP Evangelist and Community Leader http://www.rafaeldohms.com.br http://www.phpsp.org.br -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SplClassLoader RFC Voting phase
On Wed, Nov 9, 2011 at 12:04 AM, Will Fitch will.fi...@gmail.com wrote: ... I have to say, I've never heard the argument, man, if there's one thing I'd like to standardize in PHP, it'd definitely be autoloading classes. No, indeed I believe this is a group of frameworks trying to implement a standard into PHP that will help them all stay on the same page. ... As a UserLand developer. Building a new project and using libraries from various different packages is a pain, as you need to worry about the autoloading of each. The push for PSR-0 has solved this, or at least gives all library developers a heading so that new libraries that are now PSR compliant , simply allow me to drop it in a folder and at most define a rule that \Such\Namespace = vendor/ This makes life as a PHP developer much easier and having the standard valued by PHP by having a SplClassLoader that allows any library to not need to implement a autolaoder if no framework is present allows for much nicer plug and play interaction of libraries, less work for their developers and even less for the users. I'm a UG leader and i work a lot on Hackathons and pet projects, my own and guiding other people's and this is the kind of feedback i get, not having to worry about autoloading by simply having everyone follow a common structure is a very good outcome of the standards push. To me this goes much further the the framework developer and reaches the common developer. And i for one think the developer is a very important part of PHP and should be valued. -- Rafael Dohms PHP Evangelist and Community Leader http://www.rafaeldohms.com.br http://www.phpsp.org.br -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SplClassLoader RFC Voting phase
On Wed, Nov 9, 2011 at 2:03 PM, Anthony Ferrara ircmax...@gmail.com wrote: Rafael This makes life as a PHP developer much easier and having the standard valued by PHP by having a SplClassLoader that allows any library to not need to implement a autolaoder if no framework is present allows for much nicer plug and play interaction of libraries, less work for their developers and even less for the users. I would have to disagree here. When I need to use a library or a framework or whatever, I usually just bootstrap it and done. So instead of having to care about figuring out how to map the namespaces, or place them appropriately, I just call the included bootstrap.php in the library and it does the rest. You can take a peak at an example of that here: https://github.com/ircmaxell/PHP-CryptLib/blob/master/lib/CryptLib/bootstrap.php You sort of prove my point here, as you actually have your own autoloader, which in case you are PSR compliant, you would not need, you can still use your bootstrap but no longer implement the class. Also bootstrapping is not a solution for smaller libraries that include one or 2 classes, having to code an autoloader for everything is redundant. And frankly having to make sure you do requires to get the loaders is something i would rather get rid of. The day i can code a whole application without a single require in it will be a blast. If you're going for ease of use and interoperability, providing a bootstrap file is going to be king to any autoloader/naming scheme. Some libraries may have specific steps that it needs to do at startup to work. That's what a bootstrap is for. Some libraries may need to include and define functions or constants. That's what a bootstrap is for. This depends on the size of your library, bootstrapping might not be a requirement, and from what i see around its actually used very little. Anything needed is attached to your application or is done in the construct methods. Remember, libraries are more than collections of classes. They may contain other things that autoloading just doesn't take care of. Libraries can be more the collections of classes, or they can be just collection of classes. Either way my comment was directed to both cases. Sure, the thought of just being able to add it to an autoloader to take care of including the library may suffice for 90% of use cases. But it won't work (or won't work well) enough times that I'm not sure if it's even worth trying to reach for that goal. Thanks, Anthony Bootstrapping and autoloading are two parts of a process, having one done better does not exclude having the other in your library. So a see bootstrapping as a form of configuration and preparation, autoloading is merely a step that may or may not be in this. -- Rafael Dohms PHP Evangelist and Community Leader http://www.rafaeldohms.com.br http://www.phpsp.org.br -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SplClassLoader RFC Voting phase
On Wed, Nov 9, 2011 at 8:49 PM, Anthony Ferrara ircmax...@gmail.com wrote:
On Wed, Nov 9, 2011 at 5:16 PM, Rafael Dohms lis...@rafaeldohms.com.br
wrote:
On Wed, Nov 9, 2011 at 2:03 PM, Anthony Ferrara ircmax...@gmail.com wrote:
I am not PSR compliant in either autoloader implementation or class
implementation. The reason is that over time I have needed (and
removed the need, but may in the future) need to use a class name as a
reserved word. Something like XOR (which is a real example). My way
of solving that was to name the class X_OR to avoid the fatal syntax
error. But I don't want it stored in /foo/bar/x/or.php. Which would
make absolutely no semantic sense. So I went with the alternative of
/foo/bar/x_or.php (which to me makes perfect sense).
That is a problem in itself, as far as I know the final class name
does not do this kind of conversion on _ but this is a naming issue
and i personally disgree with the solution, which is beside the point
and I will not comment.
And the autoloader I built is trivial. In fact, I don't use it
everywhere (out of need). In fact, I can replicate it in 10 pretty
lines of code (+1 for the comment):
https://github.com/ircmaxell/PHP-CryptLib/blob/master/test/bootstrap.php#L33
spl_autoload_register(function ($class) {
$nslen = strlen(__NAMESPACE__);
if (substr($class, 0, $nslen) == __NAMESPACE__) {
$path = substr(str_replace('\\', '/', $class), $nslen);
$path = __DIR__ . $path . '.php';
if (file_exists($path)) {
require $path;
}
}
});
10 lines, 1 or 30 is still duplicated code which could be left out and
lessen the onus on the developer.
The point is not that it's not possible, the point is that I have to
worry about it. I need to look for it in docs, or when reading about
it. The onus is put on the user to figure that out. Whereas if I
provide a bootstrap file, all I need to communicate is just require
that bootstrap file, and today and for all time forward you'll be
fine. If you don't, and your needs change over time (due to feature
additions, etc), the way you include libraries can change. Remember,
including a library isn't just about defining an autoloader for it...
If i program by PSR (which is nothing out of the ordinary) i do not
need to worry about autoloading. If i need to worry about
bootstrapping, i'm worried with initializing, not finding and
including files.
But your comment is only applicable to class-only libraries.
Otherwise defining an autoloader is quite simply not enough. You
would then need to include the base functions/definition files.
Whereas if you used a bootstrap file, it's abstracted away from you.
Its enough to load the class, what you put in bootstrapping is
initializing and i prefer libraries that don't initialize on include,
rather that initialize when initialized, that's what factories and
contruct methods or init methods are for.. not files that initialize
as soon as they are included.
I agree that bootstrapping and autoloading are distinct parts. But
you're (by you, I mean most of the proponents of this RFC on this
list) playing it off like they are the same. A big rationale behind
including this is so that you can just distribute libraries and not
have to worry about bootstraping or setting up. But you do need to
worry about it. I'd MUCH rather see every single library include that
10 line closure than the maintainability nightmare of upgrading a
library to have mysterious things break because they changed the
initialization process on me. And that doesn't even consider the fact
that including this in core will 100% solidify the behavior for the
foreseeable future. So if a limitation or shortcoming is found (say
with the introduction of traits, or with a 5.5 or 6.0 feature), the
implementation is still stuck here for BC reasons. Leave it in
userland. Pear has done that for 12 years. Provide a common
implementation that gets installed with PEAR (or pyrus) and then just
require that as a dependency. It's worked this far, so why such a
push to change it...?
Additionally, take a look at Python. Python makes including a library
*dirt* simple. Why? Is it because it provides you with an
autoloader? Not at all (It's import method is used instead of an
autoloader, but it's distinctly different in both concept and
function). But it's also because it provides a transparent bootstrap
(the weird __init__.py file). Loading classes is only half the
battle. Others have solved this problem, don't ignore what they have
done...
So initializing has nothing to do with autoloading, furthermore,
autoloading should neither do nor trigger anything else other then
making the namespace available.
I'm not a PSR proposer, nor a framework leader, i'm a simple user who
has seen the benefit of the PSR and an autoloader, and what this
suggestion could do to library and class developers out there. Its a
standard
Re: [PHP-DEV] is gcov.php.net still useful?
On Mon, Jul 18, 2011 at 6:47 PM, Nuno Lopes nlop...@php.net wrote: Hi, So, is it worth it? Speaking as a organizer of PHP TestFest events i think GCOV is one of our most used tools to figure out what needs testing, all of our test writers need this resource to look into this. -- Rafael Dohms PHP Evangelist and Community Leader http://www.rafaeldohms.com.br http://www.phpsp.org.br -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] preg_match
I was wondering if anyone ever thought of either fixing or writing a new function that would make preg_match actually work in a way that made sense? right now i need to pass in a optional parameter that will receive the match, in this case one or no match, why should this not be the function's return already? something like: $string = tdmy text/td; $result = preg_match(/\td\(.*)\\/td\/, $string); $result // = my text Maybe something like preg_extract? I do not have the C skills to write a patch but i think adding a new function would not break BC or have negative side effects, would it? -- Rafael Dohms PHP Evangelist and Community Leader http://www.rafaeldohms.com.br http://www.phpsp.org.br -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] preg_match
On Fri, Jul 8, 2011 at 9:20 AM, Nikita Popov nikita@googlemail.com wrote:
The most common use for preg_match is validation:
if (!preg_match('~...~', $string)) { /* do something */ }
Here $matches is not required, only the 0/1 return value of preg_match is of
interest.
Furthermore, even if you need $matches, you should always combine it with an
if:
if (!preg_match('~...~', $string, $matches)) { /* do something with $matches
*/ }
Otherwise you will access $matches even though the match failed (which will
result in errors).
Thus: There is no need to change behavior here.
That is just one use case as i see it its very cluncky to use this in
case you want to extract matches, you need to initilize the $matches
variable beforehad or you get a notice, so a simple extract is now 3
lines of code.
Thus, that is the reason why i suggest a new preg_extract function
that would handle the other use cases in a optimized way.
--
Rafael Dohms
PHP Evangelist and Community Leader
http://www.rafaeldohms.com.br
http://www.phpsp.org.br
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] preg_match
Still, this is preg_match it only returns one match, why should i get a array and have to use ugly things like $matches[0] afterwards? It just makes for very ugly syntax and extra code, a simple function would make this cleaner and more intuitive, first time using preg_match is a nightmare. -- Rafael Dohms PHP Evangelist and Community Leader http://www.rafaeldohms.com.br http://www.phpsp.org.br -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [IDEA/PRE-RFC] PHP Core Mentorship Program
David, I'm no good at core code, but i can help out in the test department if newcomers need to learn to write tests for their patches -- Rafael Dohms PHP Evangelist and Community Leader http://www.rafaeldohms.com.br http://www.phpsp.org.br -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [IDEA/PRE-RFC] PHP Core Mentorship Program
On Mon, Jun 13, 2011 at 10:16 AM, David Coallier dav...@php.net wrote: See response inline. ... See Pierre, that's where I believe we are doing things wrong. We already have all our infrastructure to report bugs, create wiki pages, send emails. The goal of the program is to create something more personal, something more interactive than just sending everyone to read the manual. ... -- David Coallier I agree here with David, i think the mentorship would bring a human interface for newcomers. Yes we already get newcomers, but we could get much more if we had a human interface instead of hitting everyone with a TL;DR documentation page. Let their first interaction be with a human who can then direct to the page at given points. Mentorship has grown some awesome developers in the community, i think it can do the same in internals. And yes, we still need all of those pages described, this is an extra layer on top of everything being done. If we can get mentors who like to help the i say we go for it. -- Rafael Dohms PHP Evangelist and Community Leader http://www.rafaeldohms.com.br http://www.phpsp.org.br -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
I would prefer (as Rasmus pointed out) not to start a long discussion about it. Primarily I would be curious if anyone on the lists (from the RFC wiki page) below would like to change your vote or if you are not listed below and would like to be counted, that would be great too. i'm a +1, was not present during first vote. -- Rafael Dohms PHP Evangelist and Community Leader http://www.rafaeldohms.com.br http://www.phpsp.org.br -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator
On Thu, Mar 31, 2011 at 7:46 PM, Ben Schmidt
mail_ben_schm...@yahoo.com.au wrote:
On 1/04/11 3:29 AM, David Coallier wrote:
Hey there,
I've been working on a little patch that will allow variables ($1) in
a short-ternary operation to go through an implicit isset
(zend_do_isset_or_isempty) check so that the average use-case for the
short-ternary operator doesn't yield in a notice whenever the first
variable of the expression isn't set.
So the use-case I'm considering is the following:
?php
$list = array('name' = 'list');
echo $list['name'] ?: 'List not set.' . PHP_EOL;
echo $list['name-notset'] ?: 'List not set.' . PHP_EOL;
?
This example, which we all know, will result in a notice for the
second echo statement because the requested array-key doesn't actually
exist in the array.
I'm not familiar with the construct, but to be honest, I fail to see how
it is useful without the suppression of the notice. I mean, it's a
shorthand for isset($var)?$var:$something_else isn't it? That
presupposes that $var may not be set, but that you've accounted for that
fact, so don't want a notice about it. Obviously the isset() can only be
applied if the 'left hand side' is an lval, but I think it makes sense
to apply it whenever it is an lval.
So a big +1 from me.
Ben.
Its also a +1 for me, it would make the ternary operator much more
useful to me e remove lots of verbose code for handling arrays.
--
Rafael Dohms
PHP Evangelist and Community Leader
http://www.rafaeldohms.com.br
http://www.phpsp.org.br
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] git anyone?
As much as i might not have enough Karma to vote, being only involved in tests, but i think git would be a great fit. I agree with Phillip that we need to address the issues mentioned before if we want to move over, but our community includes guys like Travis Swicegood, who quite literally wrote the book on Git, i'm sure we can count on his help to aid us in sorting those out. I'm a +1 if we have also docs and usage examples to help the learning curve of git beginners. -- Rafael Dohms PHP Evangelist and Community Leader http://www.rafaeldohms.com.br http://www.phpsp.org.br -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] On how a little knowledge is completely useless.
On Fri, Sep 17, 2010 at 6:28 AM, Christian Kaps christian.k...@mohiva.com wrote: On Fri, 17 Sep 2010 10:02:10 +0100, Richard Quadling rquadl...@gmail.com wrote: One thing that did come to mind is if we ignore all the issues and complexities of actually implementing annotations, are annotations useful to a significant number of userland developers. On the surface, (and this is probably where I'm going wrong), it would seem to only really be of use to framework developers, and whilst there are at least 2.5 frameworks per developer, the vast majority of userland developers are not framework developers. This isn't right. At a first glance, yes it looks that only framework developers can have a benefit from annotations in the core. But the annotations extending the API of a framework so that all developers which using this frameworks have a great benefit of them. Lets take as dependency injection as example. If the framework implements this concept than the user of the framework make the usage of this. Or the bean validation framework. This is only for the framework users. I agree with Christian here, something that is for framework developers benefits all of the userland users that use that framework. So we are not looking at the minority of framework developers but at the majority of framework users. So i think the point of is there use for annotations is mute, yes there is and we don;t see more examples cause we never had it. How often did anyone suggest creating a state machine in the ZF Controller before we had goto available? once it became available we started finding uses for it. So i'm pretty sure one Annotations exist, more and more people will get familiar with it and find new ways to use it in their mindset. -- Rafael Dohms PHP Evangelist and Community Leader http://www.rafaeldohms.com.br http://www.phpsp.org.br -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Re: PHP Annotations RFC + Patch
On Wed, Sep 15, 2010 at 5:27 PM, Arvids Godjuks arvids.godj...@gmail.com wrote: Hi all. As a user land developer and active reader (and some times poster) for a few years now this is the first time I trully don't understand what the hell are you talking about and what are annotations at all and what will be the usage of them in the PHP. And for what? Building 2-3 frameworks and that's all (as I understand from reading this discussion)? As a userland user also, its about much more then this, and still, if its just for these frameworks, i'm a user of these frameworks, anything that makes it easier for me to use them or make them faster, i'm in for it. Like the doctrine example, adding a ORM layer on top of my objects just by adding annotations an not extending objects and such is a huge gain in my applications. I'm sure pretty much user land developers read this thread and ask themselves the same question. I'm also NOT asking myself this question, so its looks like 2:1 as mentioned above by Tyrael Also, discussing one interest does not stop work on all of the other features/bugs the amount of people reading and discussing here is a small percentage of the team that works on PHP. -- Rafael Dohms PHP Evangelist and Community Leader http://www.rafaeldohms.com.br http://www.phpsp.org.br -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tests repository
On Fri, Mar 12, 2010 at 9:52 PM, Pierre Joye pierre@gmail.com wrote
On Sat, Mar 13, 2010 at 12:27 AM, Stanislav Malyshev s...@zend.com wrote:
Hi!
It is possible, but that means instead of 2 trees of files you'd have these
trees distributed inside test files in a myriad of small if()s:
if(version == X) { test this error message }
elseif(version == Y) { test that error message }
else { test that another error message }
and the same for different pieces of function, etc. Why is it better?
I'm not saying it is better to write test, but it is better to
maintain one set of tests for all branches and keep them uptodate. But
that's definitivelly more work, and not only for the 1st shot. That's
why I would rather triple check if we really want to go down this way.
One thing to notice is change in output between versions.
During testfest we wrote various tests and tried to make them as
generic as possible to run in 5.2/5.3/6.
It worked in mosts tests but some suttle differences would make it a
pain to write a unified test.
For example: When writing the tests for trunk string became unicode
Whatever path PHP6 does go down, we need to rememebr small changes
like this can come along in other aspects
So just a version check for the test is not all that's needed, we need
something to deal with these differences as well.
--
Rafael Dohms
PHP Evangelist and Community Leader
http://www.rafaeldohms.com.br
http://www.phpsp.org.br
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6
2010/3/11 Johannes Schlüter johan...@php.net: On the other hand merging tests to5.2 and 5.3 means that we can find new BC breaks we had overseen and either fix them or document them properly. So I won't waste too much time but not forget about 5.2. johannes As much as I agree with the push for 5.3 adoption, its surely not a reality with most of the community out there, like the hosting companies for example. So like last year i guess we should surely focus on 5.3, but not discourage any 5.2 work and keep writing the test for all across, 5.2, 5.3, 6.0 Everyone at our test fest did that, save in cases where the functionality was not available or altered, the tests we basically the same for all versions, and i even caught a few 5.2 issues in the process. I agree in keeping the tests alive for 5.2. -- Rafael Dohms PHP Evangelist and Community Leader http://www.rafaeldohms.com.br http://www.phpsp.org.br -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Towards 5.3.2
I'm +1 on the release branching, but i'm only a test committer so my opinioin miht not weight that much here. I am however using this exact model in my own team and it has proven to do very well when tied in to Trac for tracking merges and all that. How hard would this be to add to the bug tracker? I'm kinda out of time, but i'm sure i can conjure up someone in the Brazilian Community that can take a look into it, any RFC's around? -- Rafael Dohms PHP Evangelist and Community Leader http://www.rafaeldohms.com.br http://www.phpsp.org.br -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] GD - imagecolorallocatealpha
First time suggesting a patch, please correct me if i do something wrong.
I was writing tests for imagecolorallocatealpha and noticed a change applied
in 5.3 is not in head, that is the validation of the first parameter,
delacred as 'r' in 5.3 and 'z' in HEAD (also in 5.2)
This is not a absolute problem since there is a resource type validation
right after looking for Image Resource. So i don't know how important this
fix is, but i wrote the patch below and it worked according to my tests.
I will also be commiting the tests in a few minutes.
PATCH:
Index: ext/gd/gd.c
===
--- ext/gd/gd.c(revision 287587)
+++ ext/gd/gd.c(working copy)
@@ -1729,7 +1729,7 @@
gdImagePtr im;
int ct = (-1);
-if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, z, IM,
red, green, blue, alpha) == FAILURE) {
+if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, r, IM,
red, green, blue, alpha) == FAILURE) {
RETURN_FALSE;
}
Cheers everyone!
--
Rafael Dohms
PHP Evangelist and Community Leader
http://www.rafaeldohms.com.br
http://www.phpsp.org.br
Re: [PHP-DEV] Early session timeouts on 5.2.3
Bharat Nagwani wrote: Agreed we need an upgrade. But upgrade on a large application (1000+ pages) can be expensive. As far as I can remember we had no BC breaks or function changes from 5.2.3 until 5.2.10, you should not have any problem at all to upgrade, on the contrary, you should gaina lot in performance and other tweaks. -- Rafael Dohms PHP Evangelist and Community Leader http://www.rafaeldohms.com.br http://www.phpsp.org.br
Re: [PHP-DEV] CVS Account Request: rdohms
Thank you guys. I'll check out what needs testing after the SVN migrations is 100% and i'm back from a 4 day vacation On Fri, Jul 10, 2009 at 5:58 AM, Derick Rethans der...@php.net wrote: On Fri, 10 Jul 2009, Pierre Joye wrote: On Thu, Jul 9, 2009 at 5:57 PM, Rafael Machado Dohmsrdo...@gmail.com wrote: I would like to keep writing tests for PHP as I have started in the PHP Test Fest. During this event i lead my UG to write 144 tests (PHPSP) and I myself wrote 51 tests, for the below functions: can someone approve this request please? I did that yesterday already :P regards, Derick -- http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org twitter: @derickr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Rafael Dohms PHP Evangelist and Community Leader http://www.rafaeldohms.com.br http://www.phpsp.org.br
