[PHP-DEV] suggetion: Webfronted for PHP itself
Hello, i am working on a webfrontend for php itself. For example i have a little script that writes ini settings into ini.php. I am using normal vars to write the variables into the ini file. yours sincerly Alexander Schunk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
On 04.06.2010, at 03:18, Daniel Convissor wrote: On Thu, Jun 03, 2010 at 10:29:30AM -0400, Daniel Convissor wrote: Hi Folks: On Sat, May 29, 2010 at 08:34:26PM +0300, Zeev Suraski wrote: IMHO we shouldn't be getting to any kind of fatal error/exception situation, which is why I like the idea of auto-conversion plus E_STRICT in the 'weird conversion' scenarios E_STRICT doesn't cut it. And another reason E_STRICT won't serve this situation well: how are userland error handlers supposed to pick out the type hinting conversion problems from all of the other bazillion E_STRICT errors that come up? Not very efficient. Same deal as E_NOTICE. Either you care about them or you dont. Anyway, in my weak typing proposal I also made an optional variant to get an E_FATAL instead of E_STRICT, though I personally do not see the need for it. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Suggestion: echo function(var)[0];
Hi
Why not something more generic.
Someone could think of a ValueNode.
Then it could be use for object, array, any primitive type ...
I will take the ValueNode as a non terminal grammar node.
So first we could do that:
ValueNode-method();
ValueNode::sMethod();
ValueNode[];
foo(ValueNode);
echo ValueNode;
$e = ValueNode;
...
And a ValueNode could be define as:
ValueNode :
NewStatement
| FunctionCall
| PrimitiveValue
| '(' ValueNode ')'
| ...;
This would allow all this syntax:
(new A())-foo();
foo(new A());
foo-bar()[1];
foo()[5];
and many others.
On 06/04/2010 03:19 AM, Kalle Sommer Nielsen wrote:
Hi Tig
2010/6/4 Tigtigger...@gmail.com:
Would be at all possible to implement this kind of shortcut?
Its called array-dereferencing and it was proposed countless times,
including by myself. There is an RFC for this[1] and it was planned on
the old PHP6 todo at the PDT[2].
[1] http://wiki.php.net/rfc/functionarraydereferencing
[2] http://wiki.php.net/summits/pdmnotesmay09#php_6 (see point #13)
--Mathieu Suen
Re: [PHP-DEV] Suggestion: echo function(var)[0];
On 4 June 2010 08:18, mathieu.suen mathieu.s...@easyflirt.com wrote:
Hi
Why not something more generic.
Someone could think of a ValueNode.
Then it could be use for object, array, any primitive type ...
I will take the ValueNode as a non terminal grammar node.
So first we could do that:
ValueNode-method();
ValueNode::sMethod();
ValueNode[];
foo(ValueNode);
echo ValueNode;
$e = ValueNode;
...
And a ValueNode could be define as:
ValueNode :
NewStatement
| FunctionCall
| PrimitiveValue
| '(' ValueNode ')'
| ...;
This would allow all this syntax:
(new A())-foo();
foo(new A());
foo-bar()[1];
foo()[5];
and many others.
On 06/04/2010 03:19 AM, Kalle Sommer Nielsen wrote:
Hi Tig
2010/6/4 Tigtigger...@gmail.com:
Would be at all possible to implement this kind of shortcut?
Its called array-dereferencing and it was proposed countless times,
including by myself. There is an RFC for this[1] and it was planned on
the old PHP6 todo at the PDT[2].
[1] http://wiki.php.net/rfc/functionarraydereferencing
[2] http://wiki.php.net/summits/pdmnotesmay09#php_6 (see point #13)
--Mathieu Suen
Not an expert in this area, but does this mechanism limit you to using
single dimensional arrays?
--
-
Richard Quadling
Standing on the shoulders of some very clever giants!
EE : http://www.experts-exchange.com/M_248814.html
EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Suggestion: echo function(var)[0];
On 06/04/2010 10:00 AM, Richard Quadling wrote:
On 4 June 2010 08:18, mathieu.suenmathieu.s...@easyflirt.com wrote:
Hi
Why not something more generic.
Someone could think of a ValueNode.
Then it could be use for object, array, any primitive type ...
I will take the ValueNode as a non terminal grammar node.
So first we could do that:
ValueNode-method();
ValueNode::sMethod();
ValueNode[];
foo(ValueNode);
echo ValueNode;
$e = ValueNode;
...
And a ValueNode could be define as:
ValueNode :
NewStatement
| FunctionCall
| PrimitiveValue
| '(' ValueNode ')'
| ...;
This would allow all this syntax:
(new A())-foo();
foo(new A());
foo-bar()[1];
foo()[5];
and many others.
On 06/04/2010 03:19 AM, Kalle Sommer Nielsen wrote:
Hi Tig
2010/6/4 Tigtigger...@gmail.com:
Would be at all possible to implement this kind of shortcut?
Its called array-dereferencing and it was proposed countless times,
including by myself. There is an RFC for this[1] and it was planned on
the old PHP6 todo at the PDT[2].
[1] http://wiki.php.net/rfc/functionarraydereferencing
[2] http://wiki.php.net/summits/pdmnotesmay09#php_6 (see point #13)
--Mathieu Suen
Not an expert in this area, but does this mechanism limit you to using
single dimensional arrays?
Of course not as soon as you add array access to a ValueNode
ValueNode
..
| ArrayAccess
...;
This is very simple and it can refactor greatly the parser.
-- Mathieu Suen
[PHP-DEV] Traits
A short while ago there was a discussion about implementing Traits in the next PHP version. How is the status of this? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Traits
Hi: On 04 Jun 2010, at 13:46, Christian Kaps wrote: A short while ago there was a discussion about implementing Traits in the next PHP version. How is the status of this? The code is committed to trunk, and thanks to the community there have already been some improvements and fixes for corner cases. We even got some basic reflection capabilities, too. So, it is there. Now it is just a matter of defining a release and either including it or not... Best regards Stefan PS: Snapshots are here http://snaps.php.net/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Traits
That sounds good and I hope it will be included in the next release. Best regards, Christian Hi: On 04 Jun 2010, at 13:46, Christian Kaps wrote: A short while ago there was a discussion about implementing Traits in the next PHP version. How is the status of this? The code is committed to trunk, and thanks to the community there have already been some improvements and fixes for corner cases. We even got some basic reflection capabilities, too. So, it is there. Now it is just a matter of defining a release and either including it or not... Best regards Stefan PS: Snapshots are here http://snaps.php.net/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: [PDO] Re: [PHP-DEV] [PATCH] New PDO methods for PostgreSQL driver
As far as I can see as a user PDO is quite dead and it's missing much of new database functionality. Just compare it to mysqli and other vendor specific extensions witch are developed all the time. Until there is no dedicated work for all PDO supported databases there is no point in adding features to one db driver because you essentially get the same as standalone PostgreSQL library minus the PDO overhead (especially in terms of memory, LOTS of memory). I think PHP developers should decide on PDO as a whole. For me, as an end developer, PDO is something I don't consider using because of limitations and huge memory overhead, especially in complex systems. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] New PDO methods for PostgreSQL driver
Hi, On Thu, Jun 3, 2010 at 1:58 PM, Ferenc Kovacs i...@tyrael.hu wrote: On Thu, Jun 3, 2010 at 7:28 PM, Jonathan Wage jonw...@gmail.com wrote: Hi, On Thu, Jun 3, 2010 at 1:16 PM, Ferenc Kovacs i...@tyrael.hu wrote: If that so, I would be happy to see some discussion and work on the PDO, because from a user perspective, it seems like abadoned. I think that we should allow to get things commited, because: 1, the trunk is a trunk, if something gets commited, it doesn't mean, that it will be merged for the release. Ok, that is a valid argument. But lets be real here. Chances are that if it makes it into trunk, nobody will say anything and it will make it into the final release. I disagree here, but if nobody will solve this situation until the next release, then I think its better to have _something_, than chasing away people who are contributing, and waiting something to happen. Aren't some of the other core developers willing to work together to design something to handle this? From my few discussions with Pierre it seems like that is what he wants to do and is willing to be a part of it. Take a look at the inconsistency of PHP as a whole and you'll see that this is not really a good idea. If someone, somewhere commits something it can make it into PHP and that's why PHP is in the state it is in today. So? Now we shouldn't try to improve things because they aren't perfect? No, we should work together to come up with a proper long term solution. We need to stop this and start fixing it today. Go ahed. Do you have any timeline for it? :) I'll talk with the core developers I know and see what we can make happen. I'll do whatever is needed to ensure this does not get committed. If you don't agree, you are in denial. The API of PHP now is proof. I'm agree, I'm just not seeing any progress, only excuses why should we wait for the great improvement, that should be happen anytime soon... 2, it can start a healty discussion and brainstorming about the current problem, and the solution. We're already discussing it. We don't have to commit something that is obviously wrong in order to do that. Where? The last modification in the manual was in january, and the only discussion recently on php.pdo is about extending pdo with two driver specific(both are for postgresql, one of them is this that we are talking about) feature. http://news.php.net/group.php?group=php.pdo So this is why I said, that there is no progress, just holding back the people like Denis who are willing to help, making the patch, sorting out the problems, writing testcases, doing the groundwork. If there will be a better solution(like the ones what we discussed above), and somebody will actually implement that, then this feature can be reverted as well. But right now I didn't see any work in that direction. Isn't it possible for Denis to take our recommendations and tweak his work to take into account those things? If he is interested in contributing it seems like this would be the obvious thing to do. I agree it would be nice to have those things in PHP, so can he tweak his patch to be a more proper long term solution? Thanks, Jon Tyrael -- Jonathan H. Wage (+1 415 992 5468) Open Source Software Developer Evangelist sensiolabs.com | jwage.com | doctrine-project.org | symfony-project.org You should follow me on Twitter: http://www.twitter.com/jwage You can contact Jonathan about Doctrine, Symfony and Open-Source or for training, consulting, application development, or business related questions at jonathan.w...@sensio.com
Re: [PHP-DEV] [PATCH] New PDO methods for PostgreSQL driver
On Thu, Jun 3, 2010 at 8:07 PM, Jonathan Wage jonw...@gmail.com wrote: Hi, On Thu, Jun 3, 2010 at 1:58 PM, Ferenc Kovacs i...@tyrael.hu wrote: On Thu, Jun 3, 2010 at 7:28 PM, Jonathan Wage jonw...@gmail.com wrote: Hi, On Thu, Jun 3, 2010 at 1:16 PM, Ferenc Kovacs i...@tyrael.hu wrote: If that so, I would be happy to see some discussion and work on the PDO, because from a user perspective, it seems like abadoned. I think that we should allow to get things commited, because: 1, the trunk is a trunk, if something gets commited, it doesn't mean, that it will be merged for the release. Ok, that is a valid argument. But lets be real here. Chances are that if it makes it into trunk, nobody will say anything and it will make it into the final release. I disagree here, but if nobody will solve this situation until the next release, then I think its better to have _something_, than chasing away people who are contributing, and waiting something to happen. Aren't some of the other core developers willing to work together to design something to handle this? From my few discussions with Pierre it seems like that is what he wants to do and is willing to be a part of it. As far as I know, Pierre contributes a LOT, but I dunno that he has any spare time to be involved with the actual work, but he will say this for himself. Take a look at the inconsistency of PHP as a whole and you'll see that this is not really a good idea. If someone, somewhere commits something it can make it into PHP and that's why PHP is in the state it is in today. So? Now we shouldn't try to improve things because they aren't perfect? No, we should work together to come up with a proper long term solution. I think that the only thing that block this is the actual work. We need to stop this and start fixing it today. Go ahed. Do you have any timeline for it? :) I'll talk with the core developers I know and see what we can make happen. I'll do whatever is needed to ensure this does not get committed. I think you have great chances to stop this patch to be merged into the trunk. But doing this is pointless if we can't go as far as actually discuss, plan, and _implement_ the proper solution for this problem. If you don't agree, you are in denial. The API of PHP now is proof. I'm agree, I'm just not seeing any progress, only excuses why should we wait for the great improvement, that should be happen anytime soon... 2, it can start a healty discussion and brainstorming about the current problem, and the solution. We're already discussing it. We don't have to commit something that is obviously wrong in order to do that. Where? The last modification in the manual was in january, and the only discussion recently on php.pdo is about extending pdo with two driver specific(both are for postgresql, one of them is this that we are talking about) feature. http://news.php.net/group.php?group=php.pdo So this is why I said, that there is no progress, just holding back the people like Denis who are willing to help, making the patch, sorting out the problems, writing testcases, doing the groundwork. If there will be a better solution(like the ones what we discussed above), and somebody will actually implement that, then this feature can be reverted as well. But right now I didn't see any work in that direction. Isn't it possible for Denis to take our recommendations and tweak his work to take into account those things? He expressed his willingness in this case. If he is interested in contributing it seems like this would be the obvious thing to do. I agree it would be nice to have those things in PHP, so can he tweak his patch to be a more proper long term solution? He can, but if we can't agree on (in a finite amount of time) what is proper, then he can't pass that criteria. Tyrael
Re: [PHP-DEV] [PATCH] New PDO methods for PostgreSQL driver
Hi. For me there is no problem. There were several solutions proposed in this thread: - to share connection between pdo and old pgsql driver - to create / emulate those methods in the various pdo drivers - others (look at the post of one week ago) Just point me to the right solution, give me some specifications and i'll adapt my patches. My original intention was and is to add new features and to contribute to pdo... Not to create problems. In my humble opinion the worst thing would be to do nothing after this long thread/debate. So I'll wait some feedback in order to adapt the patch. Denis Isn't it possible for Denis to take our recommendations and tweak his work to take into account those things? If he is interested in contributing it seems like this would be the obvious thing to do. I agree it would be nice to have those things in PHP, so can he tweak his patch to be a more proper long term solution? Thanks, Jon Tyrael -- Jonathan H. Wage (+1 415 992 5468) Open Source Software Developer Evangelist sensiolabs.com | jwage.com | doctrine-project.org | symfony- project.org You should follow me on Twitter: http://www.twitter.com/jwage You can contact Jonathan about Doctrine, Symfony and Open-Source or for training, consulting, application development, or business related questions at jonathan.w...@sensio.com
