Re: [PHP-DEV] Bundling "modern" extensions
Am 07.06.2011 04:42, schrieb Martin Scotta: > On Mon, Jun 6, 2011 at 8:15 PM, Reindl Harald wrote: > >> >> Am 06.06.2011 23:40, schrieb Martin Scotta: >> >>> It'd be very nice if some extension could be enabled just by dropping the >>> "extension file" on the path. >>> So developers can check what they have using phpinfo, and then upload the >>> needed extension using ftp. Is it possible? >> >> if a "developer" only would try such idiotic action >> he would lost his accounts forever and get fired from >> one day to the next! >> >> WTF how can anybody have the idea that it would be a good >> idea to let non-sysadmins uplod and execute binaries on a >> server? >> >> > Thanks you for all yours responses. > Now it's clear what the issue is... the usage of compiled "libraries". > > We need some middleware between the core and PHP. > That way extensions could be written in PHP, compiled and distributed in > some "library" format. > Library users just add them into their path, include them, and use the > classes/functions as usual. > > - No OS dependence > - minimum dependence with core version > - size of core will reduce drastically > - faster runtime, include only what libs you use, as you need them what are you speaking about and since how long you are working with PHP that you never heard about PEAR, ZendFramework? signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] 5.4 moving forward
Rasmus wrote: On 06/06/2011 08:38 PM, Lester Caine wrote: Stas Malyshev wrote: For many of us, the 5.2 branch HAS been the 'long term stability' version of PHP Any version beyond it's support period would be "long term stability" (as in "pining for the fjords" stability) by definition. If somebody want to backport patches and provide builds for it for any period he likes - sure, but nobody volunteered so far, AFAIK. This begs the question "Who decided that the only vesion of PHP available to a potentially large section of the user base should be end of lifed?" When was it voted on and was the problems of using a later version on some existing platforms even considered in that discussion? This I think is the crux of all the problems ... nobody actaully considers the end users at all? We did, the folks who actually work on this stuff. In order to move forward we need to drop old branches. Right now we are working on 3 branches, which has proven over time to be right at the limit of what we can handle. It may even be a branch more than we can handle. And much like Apache, I don't consider it our job to do binary builds for people. It is very nice that a few people have volunteered to build Windows binaries and they are available on windows.php.net as a convenience, but our primary focus is the source distribution and that's where the bulk of the attention goes. If people are building critical systems that rely on binary-only releases, they really should reconsider how they do things and at the very least install a compiler on their platform of choice and learn how to build stuff themselves. As far as I know nothing that was available in 5.2 is not available in 5.3 in source form. People who are building critical systems are in a position to make a choice, and THEY will not be using windows. But PHP was origianlly 'Personal Home Page' and I am sure that as many people are using PHP because of the 'personal' element. Those are the sort of people who 5 years ago could not afford to buy the M$ software to create their own builds, and even today some areas of windows can't be built with the free version. We tried to fill the gap by writing our own compilations to fill the gap, but today the problem is that there is simply no beginners tutorial that directs people to how they can get around the problems created by the current windows builds of PHP. I said that moving people forward to PHP5.3 was another thread, and is work that does need to be done, but simply kicking those people out into the cold is much as M$ does every version is not the way to treat users. A SIMPLE clean set of instructions on the windows download page would be a start, updating the manual to reflect the current situation, and reporting errors to third party projects that also return the wrong instructions would at least provide the assistance to users who are not in a position to build the complete compile chain that is required to work form source. Heck mine is broken again and I don't have time to sort out why, so I've not been able to update some stuff for others :( -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling "modern" extensions
Martin Scotta wrote: It'd be very nice if some extension could be enabled just by dropping the "extension file" on the path. So developers can check what they have using phpinfo, and then upload the needed extension using ftp. Is it possible? if a "developer" only would try such idiotic action he would lost his accounts forever and get fired from one day to the next! WTF how can anybody have the idea that it would be a good idea to let non-sysadmins uplod and execute binaries on a server? Thanks you for all yours responses. Now it's clear what the issue is... the usage of compiled "libraries". We need some middleware between the core and PHP. That way extensions could be written in PHP, compiled and distributed in some "library" format. Library users just add them into their path, include them, and use the classes/functions as usual. - No OS dependence - minimum dependence with core version - size of core will reduce drastically - faster runtime, include only what libs you use, as you need them That one is PEAR http://pear.php.net/ -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable typehint
Martin Scotta
On Mon, Jun 6, 2011 at 8:02 PM, Stas Malyshev wrote:
> Hi!
>
>
> The point, though, is that with such a typehint available, we can reduce
>> boilerplate code like the following:
>>
>
> Sure. How about reducing boilterplate code like this:
>
> if(is_readable($foo)) {
> $var = file_get_contents($foo);
> } else {
> throw InvalidArgumentException();
> }
>
trol?
>
> Why won't we make language construct to do that too? I don't think these
> things belong in the language syntax.
>
>
>
>> public function addCallback($callback)
>> {
>> if (!is_callback($callback)) {
>> throw new InvalidArgumentException();
>> }
>>
>> The typehint makes this simpler:
>>
>> public function addCallback(callback $callback)
>>
>>
> You understand that these two pieces of code are completely different - for
> one, you can't catch failing strict type check upstream of addCallback and
> recover.
>
>
> which allows us to rely on PHP's native error handling. I, for one,
>> would love to see this.
>>
>
> I wouldn't love it a bit, frankly, as "rely on PHP's native error handling"
> in this context means "bombing out in runtime without any idea what went
> wrong". When you have exception, you could make it print what happened and
> recover, if you want. When you have fatal error, you can't do much at all.
>
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Re: [PHP-DEV] Bundling "modern" extensions
Martin Scotta On Mon, Jun 6, 2011 at 8:15 PM, Reindl Harald wrote: > > Am 06.06.2011 23:40, schrieb Martin Scotta: > > > It'd be very nice if some extension could be enabled just by dropping the > > "extension file" on the path. > > So developers can check what they have using phpinfo, and then upload the > > needed extension using ftp. Is it possible? > > if a "developer" only would try such idiotic action > he would lost his accounts forever and get fired from > one day to the next! > > WTF how can anybody have the idea that it would be a good > idea to let non-sysadmins uplod and execute binaries on a > server? > > Thanks you for all yours responses. Now it's clear what the issue is... the usage of compiled "libraries". We need some middleware between the core and PHP. That way extensions could be written in PHP, compiled and distributed in some "library" format. Library users just add them into their path, include them, and use the classes/functions as usual. - No OS dependence - minimum dependence with core version - size of core will reduce drastically - faster runtime, include only what libs you use, as you need them
Re: [PHP-DEV] 5.4 moving forward
On 07/06/11 01:49, Stas Malyshev wrote: > Hi! > >> Currently off the shelf, 5.2.17 is the 'old stable' but for some >> windows users >> it IS the only available version. Changing the rest of the >> infrastructure to > > 5.2.17 is unsupported. It is announced on php.net. Now, some Windows > users, due to certain choices, may have to run this version - but this > doesn't change the fact it's officially unsupported. So I don't see > how it supports viability of LTS idea. Yes, and one week after support ending with announcement of 5.2.15, 5.2.16 was released again claiming that support has ended. And then a month later 5.2.17 was released, but no longer mentions that support has ended. Not too surprising then if people incorrectly assume that critical issues will continue to be fixed for 5.2. > >> package! So while PHP may have washed it's hands of the problem, >> those users who >> are stuck in the hole still need to be supported in some way. But all >> that is > > There's nothing to prevent anybody willing to do it from providing > this support. However, the question is not if there are users with > some special needs. The question is LTS, specifically: > 1. Will PHP group ever willing to support a version in LTS timeframe - > so far it never happened 5.2 was supported for about 5 years, which is what one would expect from an LTS release, so yes. It has effectively already happened. > 2. How we know we'd need to support such version UPFRONT - before it's > released? Because you say upfront how long the release will be supported. This is fairly straight-forward for any project using timed releases, which by the looks of it, is what the RFC is suggesting. How does Canonical know which Ubuntu release will be LTS? Because they decided every 4th release will be LTS. It's really not any more complicated than that. Maybe confusion is because in the past PHP has not followed timed releases, so there's no knowing how long it will be until the next version comes out. The best you can do then is promise x months of support after the next version is released. > >> being asked for is security fixes which seem to be a LOT less of a >> problem >> nowadays anyway? So support IS just a matter of maintaining >> availability to it >> and the correct builds of extensions that go with it. > > It looks to me you are confusing the question of "is LTS a viable > model for PHP development" with "if we had LTS 5 years ago, would > somebody benefit from it now". These are two different questions, and > the second one is pure theoretical since we didn't and still haven't > and I for one still don't understand how we could have it. Not intentionally, but 5.2 was supported for the time-frame expected from an LTS release. That may have given the impression that 5.3 will be supported for 5 years too, and therefore hosts can upgrade within a year or two after the release and still expect to get updates for the next 3-4 years. One thing that I think would help drive adoption of newer versions is EOL being very clearly stated. As it stands we don't know if 5.3 will continue to be supported for the next 5 years, or if it will be EOL next year. All we have to go on is what's happened in the past, and although 5.2's lifetime was an anomaly, it seems it's what people have come to expect. Cheers, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
On 06/06/2011 08:38 PM, Lester Caine wrote: > Stas Malyshev wrote: >>> For many of us, the 5.2 branch HAS been the 'long term stability' >>> version of PHP >> >> Any version beyond it's support period would be "long term stability" >> (as in "pining for the fjords" stability) by definition. If somebody >> want to backport patches and provide builds for it for any period he >> likes - sure, but nobody volunteered so far, AFAIK. > > This begs the question "Who decided that the only vesion of PHP > available to a potentially large section of the user base should be end > of lifed?" When was it voted on and was the problems of using a later > version on some existing platforms even considered in that discussion? > This I think is the crux of all the problems ... nobody actaully > considers the end users at all? We did, the folks who actually work on this stuff. In order to move forward we need to drop old branches. Right now we are working on 3 branches, which has proven over time to be right at the limit of what we can handle. It may even be a branch more than we can handle. And much like Apache, I don't consider it our job to do binary builds for people. It is very nice that a few people have volunteered to build Windows binaries and they are available on windows.php.net as a convenience, but our primary focus is the source distribution and that's where the bulk of the attention goes. If people are building critical systems that rely on binary-only releases, they really should reconsider how they do things and at the very least install a compiler on their platform of choice and learn how to build stuff themselves. As far as I know nothing that was available in 5.2 is not available in 5.3 in source form. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
Stas Malyshev wrote: For many of us, the 5.2 branch HAS been the 'long term stability' version of PHP Any version beyond it's support period would be "long term stability" (as in "pining for the fjords" stability) by definition. If somebody want to backport patches and provide builds for it for any period he likes - sure, but nobody volunteered so far, AFAIK. This begs the question "Who decided that the only vesion of PHP available to a potentially large section of the user base should be end of lifed?" When was it voted on and was the problems of using a later version on some existing platforms even considered in that discussion? This I think is the crux of all the problems ... nobody actaully considers the end users at all? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable typehint
On Mon, 6 Jun 2011, Matthew Weier O'Phinney wrote:
> The point, though, is that with such a typehint available, we can
> reduce boilerplate code like the following:
>
> public function addCallback($callback)
> {
> if (!is_callback($callback)) {
> throw new InvalidArgumentException();
> }
>
> The typehint makes this simpler:
>
> public function addCallback(callback $callback)
>
> which allows us to rely on PHP's native error handling. I, for one,
> would love to see this.
That's the same reason why I wanted scalar type hints
cheers,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable typehint
Hi Stas,
On Mon, Jun 6, 2011 at 4:02 PM, Stas Malyshev wrote:
>
> I wouldn't love it a bit, frankly, as "rely on PHP's native error handling"
> in this context means "bombing out in runtime without any idea what went
> wrong". When you have exception, you could make it print what happened and
> recover, if you want. When you have fatal error, you can't do much at all.
The patch as you probably know throws a E_RECOVERABLE_ERROR, which in
my humble opinion doesn't quite fall under the end-of-world category
you seem to explain there :- )
I.E.
function bar($a, $b, $c, $d)
{ return true; }
set_error_handler("bar");
class Foo
{
public function test(Array $arr) {}
}
$foo = new Foo; $foo->test('invalid');
echo "Everything will be okay.. :p";
-Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
On 06/05/2011 03:27 PM, Stas Malyshev wrote: This is a prime example of what we're talking about. Several have expressed a desire to follow an Ubuntu style of branching instead of the style proposed in said RFC. This is a core issue, so the RFC is certainly not ready to adopt. So does this require a new RFC, or do the RFC proposers feel this is a key concept? I think that this RFC does not contain Ubuntu-style LTS and it doesn't look like it's author(s) support it, so it should be some different point, which may be RFCed and voted on if we see substantial support for it. Speaking of which, I personally don't understand how LTS thing would work in PHP. Does it mean we'd decide out of the blue that some version would have extended support, upfront? Like, say, we now say "5.5 would have extended support"? Why would we want to do this, how would we know it? E.g., I understand if we had an option of extending support for some version post-factum, e.g., somewhere in 2015 we'd say "5.4 is so damn good and 5.5 has so many substantial changes that now we want 5.4 support to be extended another couple of years, and we feel we have people that are willing to do it". We could then talk on it and decide it, nothing prevents it. But as I understand LTS model means we'd have to decide it now, in 2011, and I don't see how it works. Could some of the proponents on this model explain it? The trunk development and the branching policy & process isn't adequately captured in the RFC. This is a gray area that should be included. It's a pity little of the mail list discussion seems to have been merged back to the RFC as clarifications, or in a comment & answer section. Chris -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling "modern" extensions
Am 06.06.2011 23:40, schrieb Martin Scotta: > It'd be very nice if some extension could be enabled just by dropping the > "extension file" on the path. > So developers can check what they have using phpinfo, and then upload the > needed extension using ftp. Is it possible? if a "developer" only would try such idiotic action he would lost his accounts forever and get fired from one day to the next! WTF how can anybody have the idea that it would be a good idea to let non-sysadmins uplod and execute binaries on a server? signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Bundling "modern" extensions
Martin Scotta wrote: It'd be very nice if some extension could be enabled just by dropping the "extension file" on the path. So developers can check what they have using phpinfo, and then upload the needed extension using ftp. Is it possible? This depends on what distribution you are using in Linux ... SUSE11.4 I have a nice array of new extensions which I can just download with package manager which will do any SUSE specific magic, such as checking for other files that need to be loaded with the extension. On windows this is not quite so easy, but is essentially the same process. We have been adding private builds of extensions that were not being included in the windows builds simply by downloading a copy from another location. As long as the file is built compatible with your PHP version that is all that is needed to add or update a single extension. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
Hi! For many of us, the 5.2 branch HAS been the 'long term stability' version of PHP Any version beyond it's support period would be "long term stability" (as in "pining for the fjords" stability) by definition. If somebody want to backport patches and provide builds for it for any period he likes - sure, but nobody volunteered so far, AFAIK. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable typehint
Hi!
The point, though, is that with such a typehint available, we can reduce
boilerplate code like the following:
Sure. How about reducing boilterplate code like this:
if(is_readable($foo)) {
$var = file_get_contents($foo);
} else {
throw InvalidArgumentException();
}
Why won't we make language construct to do that too? I don't think these
things belong in the language syntax.
public function addCallback($callback)
{
if (!is_callback($callback)) {
throw new InvalidArgumentException();
}
The typehint makes this simpler:
public function addCallback(callback $callback)
You understand that these two pieces of code are completely different -
for one, you can't catch failing strict type check upstream of
addCallback and recover.
which allows us to rely on PHP's native error handling. I, for one,
would love to see this.
I wouldn't love it a bit, frankly, as "rely on PHP's native error
handling" in this context means "bombing out in runtime without any idea
what went wrong". When you have exception, you could make it print what
happened and recover, if you want. When you have fatal error, you can't
do much at all.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling "modern" extensions
On Mon, 2011-06-06 at 18:40 -0300, Martin Scotta wrote: > It'd be very nice if some extension could be enabled just by dropping the > "extension file" on the path. > So developers can check what they have using phpinfo, and then upload the > needed extension using ftp. Is it possible? No sane sysadmin would allow this. Executing random machine code coming from some random user. Mind that this will affect all virtual hosts etc. Besides that: It probably might eventually work on Windows where there is a relatively homogeneous environment - just 4 choices (threadsafe/not-thread safe and 32 or 64 bit) not on a Unix/Linux system where there are other additional factors. And then there's this upgrade issue. When PHP is upgraded all these random modules have to upgraded, too. That's why there are package managers or the windows Installer bundling some PECL stuff (or MSFT's Web Installer thingy) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable typehint
On Mon, Jun 6, 2011 at 9:41 PM, Hannes Magnusson wrote:
> Hi
>
> As quickly mentioned in the '$arr = array('Hello', 'world'); $arr();'
> thread[1], we are hitting the need for a callable typehint.
>
>
> See attached patch+phpt; Any objections to include it in 5.4?
>
> -Hannes
>
> [1] http://php.markmail.org/message/gdas65h3im52sleg
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
+1 but please create an RFC for it, or we will argue this to death.
Tyrael
Re: [PHP-DEV] Trying to find out where the memory went
On Mon, 2011-06-06 at 22:30 +0200, Mike van Riel wrote: > 1. Does it hurt to disable the Zend MM? > 2. Can it be done from inside a PHP Script? > 3. Why is the memory consumption so much lower, even lower than my > calculations? When you disable Zend MM PHP will not use it but directly the system's allocator, which won't be counted by ZendMM therefore. you therefore loose all PHP-specific allocation improvements and the memory leak protections. Nothing you'd actually want ;-) Disabling the ZendMM is mostly useful for using memory debuggers (incl. valgrind) to do further checks. > I assume it is a good thing to at least try to create an easy way to > reproduce the issue (cannot include my test file) and create a bug > report about this :) Reproducible bug reports are always a good thing. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
Stas Malyshev wrote: Hi! The reason for the connection is simple ... currently PHP5.2 IS the LTS version for MANY users who are running windows based apache servers. Which is the only If that's what you mean by LTS, then discussing it is meaningless, as nothing here depends on us - the users will do it regardless and against out advice anyway. So why bother? Anything can be LTS. BTW, what do you think "LTS" means? Especially the "S" part? For many of us, the 5.2 branch HAS been the 'long term stability' version of PHP since our essential extensions were dropped from PHP5.3. For those people who would have difficulty replacing their current windows apache installation perhaps because it's provided as part of their hosting, then simply maintaining 5.2 as an available branch is important to them. Any dangerous security issue should be sorted because they have no chance of changing to a later build through no fault of their own. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling "modern" extensions
On Mon, 2011-06-06 at 12:53 -0400, Matthew Weier O'Phinney wrote: > > But one thing is sure, all distributions do include mongodb, > > memcache(d), couchdb, etc. If you can't run an apt-get install > > memcached (non core), just like you run apt-get install pdo_mysql > > (core), then there is something intrinsically wrong in your system. > > Or it means YOU DO NOT HAVE ROOT. > > Just because the distributions OFFER the extensions does not mean that > users have ACCESS to them. Not everyone has complete control over their > boxes, or sysadmins who are willing to update configurations. If the > functionality were available as part of core, developers would simply > have access, regardless of distribution and permissions. Which won't change a bit if we bundle it. Distributors already make stuff shared in different packages we enable(!) by default. (sqlite, xml stuff, ...) So the sysadmin already has to choose. And the choice is little affected by what we call "default" but what either the admin's preferences or some requirement document coming from somewhere ... johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling "modern" extensions
On Mon, Jun 6, 2011 at 11:40 PM, Martin Scotta wrote: > Martin Scotta > > > On Mon, Jun 6, 2011 at 2:01 PM, Pierre Joye wrote: > > > On Mon, Jun 6, 2011 at 6:53 PM, Matthew Weier O'Phinney > > wrote: > > > > > My point is that perhaps PHP has missed the boat a bit by moving > > > everything into extensions. Perhaps if an extension is particularly > > > popular, it should be incorporated into core. But let USAGE drive that, > > > not the opinions of individuals on @internals. > > > > > > I cannot disagree than with this statement. PHP is one of the language > > with the most connectivity solutions, fast adoption of new > > technologies, etc. Why? Because the language itself is relatively > > stable while its extensions are created every day for every possible > > use. > > > > However it seems that you forgot to consider what I said here a couple > > of times already. Having one nosql extension in core won't make > > hosters make the respective server side infrastructure available. How > > many hosters provide firebird? DB2? Only sqlserver is part of the > > standard windows offers but that's due to some different factors. > > > > That's why we should differentiate general purposes extensions like > > pecl's http and driver like mongo. > > > > so why mysql ext is int core? it's as specific as mongo, isn't? > > It'd be very nice if some extension could be enabled just by dropping the > "extension file" on the path. > So developers can check what they have using phpinfo, and then upload the > needed extension using ftp. Is it possible? > > that would be very bad from the security pov. including an extension should be always explicit. Tyrael
Re: [PHP-DEV] Callable typehint
Hello,
On Mon, Jun 6, 2011 at 3:51 PM, Chris Stockton
wrote:
> Hello,
>
> On Mon, Jun 6, 2011 at 12:41 PM, Hannes Magnusson
> wrote:
>> Hi
>>
>> As quickly mentioned in the '$arr = array('Hello', 'world'); $arr();'
>> thread[1], we are hitting the need for a callable typehint.
>>
>
> This brings a clear and concise enhancement to PHP which I would
> benefit from .I have been watching our API provide more and more
> functions with callbacks as arguments and it would be nice to have a
> specific type for those to clean up the is_callable error handling.
>
> It is my opinion that comparing it to previous type hinting proposals
> is like comparing apples and oranges. I think it falls in align
> justification wise between Class Name and Array type hints.
>
> I.E.
> function test1(StdClass $p) ..
> function test2(Closure $p) ... <== doesn't this seem more justified
> then "Array" given the argument of previous type hinting proposals?
> function test3(Array $arr)
>
> +1 from me
>
> -Chris
>
s/Closure/Callable/g
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable typehint
Hello,
On Mon, Jun 6, 2011 at 12:41 PM, Hannes Magnusson
wrote:
> Hi
>
> As quickly mentioned in the '$arr = array('Hello', 'world'); $arr();'
> thread[1], we are hitting the need for a callable typehint.
>
This brings a clear and concise enhancement to PHP which I would
benefit from .I have been watching our API provide more and more
functions with callbacks as arguments and it would be nice to have a
specific type for those to clean up the is_callable error handling.
It is my opinion that comparing it to previous type hinting proposals
is like comparing apples and oranges. I think it falls in align
justification wise between Class Name and Array type hints.
I.E.
function test1(StdClass $p) ..
function test2(Closure $p) ... <== doesn't this seem more justified
then "Array" given the argument of previous type hinting proposals?
function test3(Array $arr)
+1 from me
-Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
Hi! The reason for the connection is simple ... currently PHP5.2 IS the LTS version for MANY users who are running windows based apache servers. Which is the only If that's what you mean by LTS, then discussing it is meaningless, as nothing here depends on us - the users will do it regardless and against out advice anyway. So why bother? Anything can be LTS. BTW, what do you think "LTS" means? Especially the "S" part? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bug #39863 in trunk/5.4
Hi! Ok, I've committed in 5.4 and trunk the argument parser part. Now I need to fix some tests and try to found other places needing for related checks. Thanks for fixing it! -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
Stas Malyshev wrote: As much as I appreciate everybody taking this opportunity to vent about their troubles with Apache on Windows, could we not hijack this topic - which was about release management and in particular LTS - and turn it into Apache on Windows topic? We can have separate Apache on Windows topic where people can share their pain and trade solutions. The reason for the connection is simple ... currently PHP5.2 IS the LTS version for MANY users who are running windows based apache servers. Which is the only reason that I was suggesting that this is part of the discussion on setting a current LTS. It's not just chnages to the internal operation of PHP that causes problems for users, simply installing a working copy is somewhat important? Moving those users forward to the current builds is another thread that needs addressing. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable typehint
Hi, On Mon, Jun 6, 2011 at 22:35, Stas Malyshev wrote: > Hi! > >> See attached patch+phpt; Any objections to include it in 5.4? > > Yes, same objections as for other static typing. Those objections do not apply here IMO. IIRC, the main objections were that if we introduce strict hints for scalar values, then we start rejecting stuff that would "just work" via implicit conversions before. i.e. "2" vs 2. In this case, if you don't provide a valid callback to a function expecting a valid callback, there is no way it will "just work". Just like with other type hints, if you write function foo(A $b) and pass B which is not a subtype of A, there is no way foo() will "just work", as there is no way it will be able to interpret the value, an object of type B, as an object of type A. +1 from me, this seems very useful. > > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Etienne Kneuss http://www.colder.ch -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable typehint
On 2011-06-06, Pierre Joye wrote:
> --0016e6de0029ddc06f04a5129914
> Content-Type: text/plain; charset=ISO-8859-1
>
> How is this argument different than the one in favor of type hinting (or
> whatever was what ended in trunk)?
I was simply voicing my support for Hannes' patch, and trying to clarify
my understanding of it for Stas.
If you're comparing it to the scalar typehinting patch, I think it's a
far cry from that -- this is about providing a unified typehint for
functionality represented over multiple constructs in PHP, in order to
reduce code in applications. If it offers no BC issues, and allows
developers to simplify code and remove boilerplate (which can easily
introduce new errors on each iteration), then why wouldn't it be a good
idea?
> On 7 Jun 2011 00:16, "Matthew Weier O'Phinney"
> wrote:
> > On 2011-06-06, Stas Malyshev wrote:
> > > > Like I mentioned in the other thread (which I probably should had
> > > > repeated here), a lot of libs/frameworks are using the 'Closure'
> > > > typehint for callbacks.
> > >
> > > Well, they are wrong (unless they mean to use only closures and not
> > > callbacks). But that's no reason to do wrong thing in the language
> > > too.
> > >
> > > > The problem with that is a function name as a string and
> > > > array("classname", "functionname") are considered is_callable(). To
> > > > get through the intentions of the Closure hint, I would have to wrap
> > > > the actual callback in a closure - which doesn't make any sense.
> > >
> > > "callable" is not actually even a type. If we make it a language
> > > construct, then why 'authenticated DB connection', 'name of readable
> > > file', 'valid stream URL', 'validated XML', 'string in UTF-8 no longer
> > > than 255 characters' or 'balanced binary tree' is not a language
> > > construct? I don't think we need to put every data check into the
> > > language, especially that it actually makes it worse - you can
> > > gracefully handle user-space check, but not a strict typing error.
> >
> > The point, though, is that with such a typehint available, we can reduce
> > boilerplate code like the following:
> >
> > public function addCallback($callback)
> > {
> > if (!is_callback($callback)) {
> > throw new InvalidArgumentException();
> > }
> >
> > The typehint makes this simpler:
> >
> > public function addCallback(callback $callback)
> >
> > which allows us to rely on PHP's native error handling. I, for one,
> > would love to see this.
> >
> > --
> > Matthew Weier O'Phinney
> > Project Lead | matt...@zend.com
> > Zend Framework | http://framework.zend.com/
> > PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>
> --0016e6de0029ddc06f04a5129914--
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable typehint
How is this argument different than the one in favor of type hinting (or
whatever was what ended in trunk)?
On 7 Jun 2011 00:16, "Matthew Weier O'Phinney"
wrote:
> On 2011-06-06, Stas Malyshev wrote:
>> > Like I mentioned in the other thread (which I probably should had
>> > repeated here), a lot of libs/frameworks are using the 'Closure'
>> > typehint for callbacks.
>>
>> Well, they are wrong (unless they mean to use only closures and not
>> callbacks). But that's no reason to do wrong thing in the language
>> too.
>>
>> > The problem with that is a function name as a string and
>> > array("classname", "functionname") are considered is_callable(). To
>> > get through the intentions of the Closure hint, I would have to wrap
>> > the actual callback in a closure - which doesn't make any sense.
>>
>> "callable" is not actually even a type. If we make it a language
>> construct, then why 'authenticated DB connection', 'name of readable
>> file', 'valid stream URL', 'validated XML', 'string in UTF-8 no longer
>> than 255 characters' or 'balanced binary tree' is not a language
>> construct? I don't think we need to put every data check into the
>> language, especially that it actually makes it worse - you can
>> gracefully handle user-space check, but not a strict typing error.
>
> The point, though, is that with such a typehint available, we can reduce
> boilerplate code like the following:
>
> public function addCallback($callback)
> {
> if (!is_callback($callback)) {
> throw new InvalidArgumentException();
> }
>
> The typehint makes this simpler:
>
> public function addCallback(callback $callback)
>
> which allows us to rely on PHP's native error handling. I, for one,
> would love to see this.
>
> --
> Matthew Weier O'Phinney
> Project Lead | matt...@zend.com
> Zend Framework | http://framework.zend.com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
Re: [PHP-DEV] Re: Voting Process (was: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward))
On 2011-06-06, Chad Fulton wrote: > So, I would advocate a "white list" of core devs for formal voting (of > which, for example, I would not be a member). I think this mailing > list has grown sufficiently that "public opinion" can be gauged from > here: everyone can write their opinion without giving them voting > privileges. > > If you haven't already, I recommend you read the (incredibly long) > discussions from last summer on type-hinting. They convinced me that > sometimes a feature that sounds good is simply not a good fit for PHP > for reasons which many did not (still do not?) understand. I think your analysis is great. That said, I think if this is the route ultimately taken, any time an RFC is voted out, a summary of the _technical_ reasons for denying it should be provided. Usually there are very good ones -- but this information can be invaluable to anybody who may want to ressurect the RFC in the future to ensure they don't hit the same pitfalls. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable typehint
On 2011-06-06, Stas Malyshev wrote:
> > Like I mentioned in the other thread (which I probably should had
> > repeated here), a lot of libs/frameworks are using the 'Closure'
> > typehint for callbacks.
>
> Well, they are wrong (unless they mean to use only closures and not
> callbacks). But that's no reason to do wrong thing in the language
> too.
>
> > The problem with that is a function name as a string and
> > array("classname", "functionname") are considered is_callable(). To
> > get through the intentions of the Closure hint, I would have to wrap
> > the actual callback in a closure - which doesn't make any sense.
>
> "callable" is not actually even a type. If we make it a language
> construct, then why 'authenticated DB connection', 'name of readable
> file', 'valid stream URL', 'validated XML', 'string in UTF-8 no longer
> than 255 characters' or 'balanced binary tree' is not a language
> construct? I don't think we need to put every data check into the
> language, especially that it actually makes it worse - you can
> gracefully handle user-space check, but not a strict typing error.
The point, though, is that with such a typehint available, we can reduce
boilerplate code like the following:
public function addCallback($callback)
{
if (!is_callback($callback)) {
throw new InvalidArgumentException();
}
The typehint makes this simpler:
public function addCallback(callback $callback)
which allows us to rely on PHP's native error handling. I, for one,
would love to see this.
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bug #39863 in trunk/5.4
Hi, 2011/6/5 Stas Malyshev > Hi! > > > Of course, I was just checking if it's what you guys are thinking first. >> > > Well, there was basically two ideas: > 1. Add filename length to streams and check inside streams > 2. Check inside argument parser > > Both have downsides: (1) does not capture cases when we don't use streams > (such as direct stat/touch/etc functions), (2) doesn't cover the case when > stream is manipulated through a string not coming directly from a function > argument (e.g. include, but may be other cases with extensions). So, > ideally, it'd be nice to have both - or something third that I didn't think > of - but any of them is better than nothing. > (1) seems to be easier and less disruptive, provided that we cover include > case separately and locate all functions that deal with filenames. > > Ok, I've committed in 5.4 and trunk the argument parser part. Now I need to fix some tests and try to found other places needing for related checks. Thanks. -- Regards, Felipe Pena
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
Martin Scotta On Mon, Jun 6, 2011 at 3:03 PM, Matthew Weier O'Phinney < weierophin...@php.net> wrote: > On 2011-06-01, Sean Coates wrote: > > > Now, the only reason I would personally support the array shortcut is > > > if it was an implementation of JSON. I know that's not on the table > > > here > > > > I don't think anything is officially off the table, unless we forego > > discussion. > > > > My application is largely JSON-powered. We pass data from back- to > > front-end via JSON, we interact with MongoDB via the extension (which > > is an altered JSON-like protocol (arrays instead of objects), but > > would be a lot more fluent with actual objects—they're just too hard > > to make in current PHP), and we interface with ElasticSearch. The > > paste I linked earlier is our primary ElasticSearch query. > > > > The benefits of first-class JSON are important and wide-reaching; > > especially when interacting with systems like the ones I've mentioned. > > There's a huge amount of value in being able to copy JSON out of PHP > > and into e.g. CURL to make a query to ElasticSearch without worrying > > that I've accidentally nested one level too deep or shallow, or > > accidentally mistranslating my arrays into JSON. > > > > This is not about saving five characters every time I type array(), > > it's about making my systems all work together in a way that's a > > little less abstracted, and a lot less prone to error. > > *applause* > > Well, said, Sean. Basically, this discussion should be likened to > adding SimpleXML to PHP -- providing tools that make interoperability > with other systems or languages simpler. > I don't believe this discution will lead to something. 1) Core devs don't want to change the langt. ...and linked with the "modern" bundle thread... 2) if you get this feature in the php version --let's say-- 5.4, it will not be installed on your shared hosting. equals) feature not available > > -- > Matthew Weier O'Phinney > Project Lead| matt...@zend.com > Zend Framework | http://framework.zend.com/ > PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] $arr = array('Hello', 'world'); $arr();
Hi,
2011/6/6 Dmitry Stogov
> Hi Felipe,
>
> I like the idea. It makes indirect method calls less expensive.
>
> I would add a hint to specializer, to eliminate small overhead for regular
> function calls.
>
> } else if (OP1_TYPE != IS_CONST &&
> EXPECTED(Z_TYPE_P(function_name) == IS_ARRAY) &&
> zend_hash_num_elements(Z_ARRVAL_P(function_name)) == 2) {
>
> Thanks. Dmitry.
Dmitry:
Oh, right. I added the check for OP2_TYPE != IS_CONST, thanks for reviewing.
Christopher Jones:
Alright, I'll write a page in the wiki for the record.
All:
Committed in 5.4 and trunk now.
Thanks for the comments, folks! :)
--
Regards,
Felipe Pena
Re: [PHP-DEV] Bundling "modern" extensions
Martin Scotta On Mon, Jun 6, 2011 at 2:01 PM, Pierre Joye wrote: > On Mon, Jun 6, 2011 at 6:53 PM, Matthew Weier O'Phinney > wrote: > > > My point is that perhaps PHP has missed the boat a bit by moving > > everything into extensions. Perhaps if an extension is particularly > > popular, it should be incorporated into core. But let USAGE drive that, > > not the opinions of individuals on @internals. > > > I cannot disagree than with this statement. PHP is one of the language > with the most connectivity solutions, fast adoption of new > technologies, etc. Why? Because the language itself is relatively > stable while its extensions are created every day for every possible > use. > > However it seems that you forgot to consider what I said here a couple > of times already. Having one nosql extension in core won't make > hosters make the respective server side infrastructure available. How > many hosters provide firebird? DB2? Only sqlserver is part of the > standard windows offers but that's due to some different factors. > > That's why we should differentiate general purposes extensions like > pecl's http and driver like mongo. > > so why mysql ext is int core? it's as specific as mongo, isn't? It'd be very nice if some extension could be enabled just by dropping the "extension file" on the path. So developers can check what they have using phpinfo, and then upload the needed extension using ftp. Is it possible? > Cheers, > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] Re: Voting Process (was: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward))
On Mon, Jun 6, 2011 at 12:27 PM, dukeofgaming wrote: > > I have a little proposition here. > > I'm not —at least currently— known for any app or framework, but I'd like my > voice to count, that is, if and only if the rest of the community thinks I > make sane arguments that are worth considering. > > I'm perfectly aware that the fame one could gain from taking production code > to visible success should be an indicator of an educated opinion, however, I > think this might lead to a closed group who can vote, and I like the > openness of this community, even if the general process is chaotic, it still > gets the warm and fuzzy feeling of an open source community. > > OTOH, if a completely open group's votes were all considered, the final > decision could just end up being a matter of numbers outnumbering other > numbers. If I get it right, this is the current problem. > > So my proposal is that the voting privilege could be given on the basis of a > *web of trust*, and if I'm not mistaken this is a little like what the > concept of karma works here (I'm fairly new here). Not sure if there should > be a voting to elect voters or if it could/should be something more lax, but > I don't think the requirement to vote should be fame. I'm similarly placed (as are many here I think), in the sense that I have not done any internals work and I am not one of the lead devs for a well-known project. Much as I think my opinions are great, I don't believe we should have a vote or, if we do, that it shouldn't count for as much as others', for the following reasons: - Long-term commitment: we want people voting who (1) know the history of past PHP discussions on topics and why they were rejected or postponed, (2) understand the "PHP way", and (3) have shown commitment to *maintaining* PHP - Perspective: developing *with* PHP is not the same as developing *for* PHP internals. Feasibility, interoperability, maintenance concerns, and more are things that, as long as I've read the list, are often misunderstood or downplayed by people who develop *with* PHP and want a shiny new feature (including me). - Unified vision: we want people who are taking the whole PHP picture into account to be the ones doing the voting. Much of the volume on the list is very narrowly focused - this is a good thing for discussion of specific features, but a bad thing for picking which features to include in PHP. So, I would advocate a "white list" of core devs for formal voting (of which, for example, I would not be a member). I think this mailing list has grown sufficiently that "public opinion" can be gauged from here: everyone can write their opinion without giving them voting privileges. If you haven't already, I recommend you read the (incredibly long) discussions from last summer on type-hinting. They convinced me that sometimes a feature that sounds good is simply not a good fit for PHP for reasons which many did not (still do not?) understand. Chad Fulton -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable typehint
Hi!
Like I mentioned in the other thread (which I probably should had
repeated here), a lot of libs/frameworks are using the 'Closure'
typehint for callbacks.
Well, they are wrong (unless they mean to use only closures and not
callbacks). But that's no reason to do wrong thing in the language too.
The problem with that is a function name as a string and
array("classname", "functionname") are considered is_callable().
To get through the intentions of the Closure hint, I would have to
wrap the actual callback in a closure - which doesn't make any sense.
"callable" is not actually even a type. If we make it a language
construct, then why 'authenticated DB connection', 'name of readable
file', 'valid stream URL', 'validated XML', 'string in UTF-8 no longer
than 255 characters' or 'balanced binary tree' is not a language
construct? I don't think we need to put every data check into the
language, especially that it actually makes it worse - you can
gracefully handle user-space check, but not a strict typing error.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $arr = array('Hello', 'world'); $arr();
On 06/05/2011 08:52 AM, Felipe Pena wrote:
Hi all,
Reading our bug tracker I noticed a good feature request [1] from 2009 which
points to an interesting feature that I think makes sense for us, since we
are now working with $f() using objects and strings, and the array('class',
'method') is an old known for call_user_func()-like functions.
[...]
> Any thoughts?
Felipe,
How about collating the emails and examples and creating an RFC for it?
Chris
--
Email: christopher.jo...@oracle.com
Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable typehint
On 06/06/2011 12:41 PM, Hannes Magnusson wrote: See attached patch+phpt; Any objections to include it in 5.4? Hannes, How about putting up an RFC for it? Even a brief RFC would be better than none. Chris -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable typehint
On Mon, Jun 6, 2011 at 22:35, Stas Malyshev wrote:
> Hi!
>
>> See attached patch+phpt; Any objections to include it in 5.4?
>
> Yes, same objections as for other static typing.
>
That was totally not the purpose of this, and I don't quite understand
how you made the connection.
Like I mentioned in the other thread (which I probably should had
repeated here), a lot of libs/frameworks are using the 'Closure'
typehint for callbacks.
The problem with that is a function name as a string and
array("classname", "functionname") are considered is_callable().
To get through the intentions of the Closure hint, I would have to
wrap the actual callback in a closure - which doesn't make any sense.
-Hannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
Hi! A PHP developers view on windows installation: it's screwed as hell right now. I use apache + php for my developing envoirment on Windows 7. Guys - I spend 1.5, freaking 1.5 hours setting up apache + php!!! essentially i just As much as I appreciate everybody taking this opportunity to vent about their troubles with Apache on Windows, could we not hijack this topic - which was about release management and in particular LTS - and turn it into Apache on Windows topic? We can have separate Apache on Windows topic where people can share their pain and trade solutions. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable typehint
Hi! See attached patch+phpt; Any objections to include it in 5.4? Yes, same objections as for other static typing. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Trying to find out where the memory went
David and Pauli, When I change the test script to: var_dump(memory_get_peak_usage()); gc_collect_cycles(); token_get_all(file_get_contents()); gc_collect_cycles(); var_dump(memory_get_peak_usage()); And execute the following bash line preceding: export USE_ZEND_ALLOC=0 I get the following output: int(8240) int(8240) When I remove the gc_collect_cycles I get the same result. Even assigning the results to a variable do not increase the peak memory. FYI: When I change the argument of memory_get_peak_usage to 'true', I get the following results: int(262144) int(262144) This amount is astoundingly less than the previous conclusions and less than my own calculations would show. Of course this leads me to the following questions: 1. Does it hurt to disable the Zend MM? 2. Can it be done from inside a PHP Script? 3. Why is the memory consumption so much lower, even lower than my calculations? I assume it is a good thing to at least try to create an easy way to reproduce the issue (cannot include my test file) and create a bug report about this :) Thank you for your assistance thus far. Mike On Sun, 5 Jun 2011 15:36:43 +0200, Julien Pauli wrote: Seems like leak. Try disabling ZendMM to see if something noticeable happens (memory peak should be lower). USE_ZEND_ALLOC=0 Cheers, Julien On Sun, Jun 5, 2011 at 2:01 PM, David Zülke wrote: Smells like a memory leak if gc_collect_cycles() doesn't fix it. David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Object and Array Literals
>>> $foo = {
>>> 'bar' : function(){
>>> echo 'baz';
>>> }
>>> };
>>>
>>> $foo->bar();
>>
>> I guess it's not yet too late to surpass Perl in the front of obscurity...
>
> Since the stuff to the right of the assignment operator (`:` in this case) is
> valid PHP, I don't see why this wouldn't be allowed if we adopt the {}
> syntax. It's not much different from this, which is currently valid:
>
> $foo = (object)array(
> 'bar' => function () {
>echo 'baz';
> }
> };
Matthew pointed out to me (on IRC) that this actually doesn't work in current
PHP (you can't call an object property as a closure without one of the proxy
functions like call_user_function_array()). My mistake.
Note that this shouldn't affect the RFC, and this behaviour should be addressed
as a separate issue if people think it should work (FWIW, I do obviously think
this should work, but that's a separate thread, please).
S
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Callable typehint
Hi
As quickly mentioned in the '$arr = array('Hello', 'world'); $arr();'
thread[1], we are hitting the need for a callable typehint.
See attached patch+phpt; Any objections to include it in 5.4?
-Hannes
[1] http://php.markmail.org/message/gdas65h3im52sleg
Index: Zend/zend.h
===
--- Zend/zend.h (revision 311867)
+++ Zend/zend.h (working copy)
@@ -573,6 +573,7 @@
#define IS_RESOURCE7
#define IS_CONSTANT8
#define IS_CONSTANT_ARRAY 9
+#define IS_CALLABLE10
/* Ugly hack to support constants as static array indices */
#define IS_CONSTANT_TYPE_MASK 0x00f
Index: Zend/zend_execute.c
===
--- Zend/zend_execute.c (revision 311867)
+++ Zend/zend_execute.c (working copy)
@@ -626,13 +626,24 @@
need_msg = zend_verify_arg_class_kind(cur_arg_info,
fetch_type, &class_name, &ce TSRMLS_CC);
return zend_verify_arg_error(E_RECOVERABLE_ERROR, zf,
arg_num, need_msg, class_name, zend_zval_type_name(arg), "" TSRMLS_CC);
}
- } else if (cur_arg_info->type_hint && cur_arg_info->type_hint ==
IS_ARRAY) {
- if (!arg) {
- return zend_verify_arg_error(E_RECOVERABLE_ERROR, zf,
arg_num, "be of the type array", "", "none", "" TSRMLS_CC);
- }
+ } else if (cur_arg_info->type_hint) {
+ switch(cur_arg_info->type_hint) {
+ case IS_ARRAY:
+ if (!arg) {
+ return
zend_verify_arg_error(E_RECOVERABLE_ERROR, zf, arg_num, "be of the type array",
"", "none", "" TSRMLS_CC);
+ }
- if (Z_TYPE_P(arg) != IS_ARRAY && (Z_TYPE_P(arg) != IS_NULL ||
!cur_arg_info->allow_null)) {
- return zend_verify_arg_error(E_RECOVERABLE_ERROR, zf,
arg_num, "be of the type array", "", zend_zval_type_name(arg), "" TSRMLS_CC);
+ if (Z_TYPE_P(arg) != IS_ARRAY && (Z_TYPE_P(arg) !=
IS_NULL || !cur_arg_info->allow_null)) {
+ return
zend_verify_arg_error(E_RECOVERABLE_ERROR, zf, arg_num, "be of the type array",
"", zend_zval_type_name(arg), "" TSRMLS_CC);
+ }
+ break;
+ case IS_CALLABLE:
+ if (!zend_is_callable(arg, IS_CALLABLE_CHECK_SILENT,
NULL) && (Z_TYPE_P(arg) != IS_NULL || !cur_arg_info->allow_null)) {
+ return
zend_verify_arg_error(E_RECOVERABLE_ERROR, zf, arg_num, "be callable", "",
zend_zval_type_name(arg), "" TSRMLS_CC);
+ }
+ break;
+ default:
+ zend_error(E_ERROR, "Unknown typehint");
}
}
return 1;
Index: Zend/zend_language_scanner.l
===
--- Zend/zend_language_scanner.l(revision 311867)
+++ Zend/zend_language_scanner.l(working copy)
@@ -1310,6 +1310,10 @@
return T_ARRAY;
}
+"callable" {
+ return T_CALLABLE;
+}
+
"++" {
return T_INC;
}
Index: Zend/zend_compile.c
===
--- Zend/zend_compile.c (revision 311867)
+++ Zend/zend_compile.c (working copy)
@@ -1849,28 +1849,40 @@
cur_arg_info->allow_null = 0;
if (class_type->u.constant.type != IS_NULL) {
- cur_arg_info->type_hint = IS_OBJECT;
- if (ZEND_FETCH_CLASS_DEFAULT ==
zend_get_class_fetch_type(Z_STRVAL(class_type->u.constant),
Z_STRLEN(class_type->u.constant))) {
- zend_resolve_class_name(class_type,
&opline->extended_value, 1 TSRMLS_CC);
- }
- class_type->u.constant.value.str.val =
zend_new_interned_string(class_type->u.constant.value.str.val,
class_type->u.constant.value.str.len + 1, 1 TSRMLS_CC);
- cur_arg_info->class_name =
class_type->u.constant.value.str.val;
- cur_arg_info->class_name_len =
class_type->u.constant.value.str.len;
- if (op == ZEND_RECV_INIT) {
- if (Z_TYPE(initialization->u.constant) ==
IS_NULL || (Z_TYPE(initialization->u.constant) == IS_CONSTANT &&
!strcasecmp(Z_STRVAL(initialization->u.constant), "NULL"))) {
- cur_arg_info->allow_null = 1;
- } else {
- zend_error(E_COMPILE_ERROR, "Default
value for parameters with a class type hint can only be NULL");
+ if (class_type->u.constant.type == IS_ARRAY) {
+ cur_arg_info->type_hint = IS_ARRAY;
+ if (op == ZEND_RECV_INIT) {
+
Re: [PHP-DEV] Re: Voting Process (was: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward))
On Sun, Jun 5, 2011 at 5:20 PM, Pierre Joye wrote: > > > I'd to go with a 60% for language syntax, 50+1 for new exts or sapis. > Other question is who can vote. For one, I like to have external > people being able to vote, like frameworks/apps lead developers as > well as @php.net in general (docs people at the same level than core > devs, no diff). I have a little proposition here. I'm not —at least currently— known for any app or framework, but I'd like my voice to count, that is, if and only if the rest of the community thinks I make sane arguments that are worth considering. I'm perfectly aware that the fame one could gain from taking production code to visible success should be an indicator of an educated opinion, however, I think this might lead to a closed group who can vote, and I like the openness of this community, even if the general process is chaotic, it still gets the warm and fuzzy feeling of an open source community. OTOH, if a completely open group's votes were all considered, the final decision could just end up being a matter of numbers outnumbering other numbers. If I get it right, this is the current problem. So my proposal is that the voting privilege could be given on the basis of a *web of trust*, and if I'm not mistaken this is a little like what the concept of karma works here (I'm fairly new here). Not sure if there should be a voting to elect voters or if it could/should be something more lax, but I don't think the requirement to vote should be fame. Best regards, David
Re: [PHP-DEV] 5.4 moving forward
Hello. A PHP developers view on windows installation: it's screwed as hell right now. I use apache + php for my developing envoirment on Windows 7. Guys - I spend 1.5, freaking 1.5 hours setting up apache + php!!! essentially i just had to download and try multiple binaries for windows to find the right one. The first time I did that it was two evenings. Now i know that i need a VC9 threaded version and i haveto go to the Perries page to get extensions. Sometimes you have to fish the google to find some extenension that works and not fails to load. To my liking the situation is ridicilous. The manual has to be updated and windows support should be restored to full strength as it was. Many developers work on windows because many of us do not have the time or will to dive into linux and fine toon it and spend weeks finding software that is adiquite. And mostly windows based software is usually winning in features and quality, and most importantly - usability. Tried, but had to return to windows. Maybe you just don't get that kind of feedback becase internals list isn't what usually people read. Set up an official forums and people will start to post. 06.06.2011 20:51 пользователь "Stas Malyshev" написал: > Hi! > >> Media Temple's Grid servers still default to PHP 4.4.9. With the option of >> using 5.2.16, but you have to explicitly tell it to use that version in your >> .htaccess file. > > This is pretty bad, but LTS would only make this problem worse - imagine > if 4.4 were LTS, they'd say "oh, we are installing only long-term > versions, we are long-term vision people!". Now at least they don't have > the excuse :) > > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
Re: [PHP-DEV] 5.4 moving forward
On 06/06/2011 01:48 AM, Tom Samplonius wrote: So RHEL6 will have whatever PHP that was around, then, which I hope is PHP 5.3 (I don't have any RHEL6 servers yet). So RHEL6 will always be PHP5.3.x based. RHEL 6.0's php-* packages are PHP 5.3.2. RHEL 6.1's uses PHP 5.3.3. RHEL 5.6 has a set of php53-* packages with PHP 5.3.3. This augments the RHEL 5.x php-* packages that are PHP 5.1.6. Chris PS -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
Hi! Media Temple's Grid servers still default to PHP 4.4.9. With the option of using 5.2.16, but you have to explicitly tell it to use that version in your .htaccess file. This is pretty bad, but LTS would only make this problem worse - imagine if 4.4 were LTS, they'd say "oh, we are installing only long-term versions, we are long-term vision people!". Now at least they don't have the excuse :) -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
Pierre Joye wrote: However I ask you, strongly, now to stop to pollute this thread with totally unrelated topics. Thanks for your understanding. This is something of a rather important point since PHP has always been very strongly related to Apache so it is totally related to a discussion of moving PHP forward. Currently the mainstream information is so far adrift of the present situation that at it needs to be addressed. A starting point would be to bring all of the PHP manual information in line with the current situation and point people to the preferred installation paths rather than telling people to use steps that do not actually get to a working PHP5.3 setup? And starting to push out 5.4 will increase peoples requests to getting things working with exiting windows/apache/php5.2 setups. Does anybody other than Pierre disagree with the point that currently the mainstream windows installation paths are something of a mess and needs to be updated in some way? I've been updating my own installation guides, but I had not realised just how many other PHP projects provide windows installation guides that no longer work. Not having been using windows myself on new builds for some time, I had not updated and tested clean installs and it's only recently I've found how out of date things are :( I've been getting emails from people asking why my guides were not working hence the need to address this and get back to a working situation. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
On Mon, Jun 6, 2011 at 8:11 PM, Lester Caine wrote: > PERHAPS such important information could be made available to REAL USERS? > There has never been any public statement to that effect! For the 10th time, please stop to uppercase every 2nd word. > Until you came on the scene I had never even had to look at compiling > anything in the FWAP or FLAP stack, After months of endless discussions, the reasons why we stop to support a 16 years old compiler (please notice the "we", not the "I") are still black magic to your eyes. I'm sorry that I did not succeed to explain it better. However I ask you, strongly, now to stop to pollute this thread with totally unrelated topics. Thanks for your understanding. -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
Media Temple's Grid servers still default to PHP 4.4.9. With the option of using 5.2.16, but you have to explicitly tell it to use that version in your .htaccess file. On Mon, Jun 6, 2011 at 2:03 PM, John Crenshaw wrote: > > From: David Muir [mailto:davidkm...@gmail.com] > > On 06/06/11 17:48, Tom Samplonius wrote: > >> Currently - A lot of ISP's are 'stuck' with PHP5.2 or earlier simply > > I don't know if this is really the case. > > The problem is much larger than most of us would probably like to believe. > Some of the major hosts, (like GoDaddy) offer 5.3 as an htaccess swap, but > many others don't. For example, Rackspace still hasn't upgraded their Cloud > Sites offering and it seems that Bluehost is also still on 5.2. > >
Re: [PHP-DEV] 5.4 moving forward
Pierre Joye wrote: > Please can you provide a link where THAT statement is made! Chech the php windows internals list archive as well as the httpd devel ones. This statement has been written numerous times in both lists. PERHAPS such important information could be made available to REAL USERS? There has never been any public statement to that effect! Until you came on the scene I had never even had to look at compiling anything in the FWAP or FLAP stack, everything just worked from the precompiled downloads linked to by the tutorials. EVEN the php manual STILL starts a windows apache install with a download of the .msi from apache! That is one of the first hit on google and bing for "install apache php on windows" and every one of the links I checked starting with Drupal say "Download the Apache Windows MSI Installer from Apache.org". I've updated my own FWAP installation tutorial to use the Apachelounge installer but one has to go a long way down the google or bing results to find any reference to apachelounge at all :( So a few people saying that this is not an official version of Apache makes no difference to the probably millions of users who follow the directions to install Apache and then find problems adding PHP to it ... and start asking 'where is the VC6 version of PHP5.3' everywhere other than on the PHP lists. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- 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)
On 06.06.2011, at 20:03, John Crenshaw wrote: > The desire is to be able to copy/paste things back and forth and make it work > with only minor tweaks. That sounds like a problem an IDE should solve, and not the language itself. And again... there are potential encoding problems, plus single versus double quotes, trailing commas, and so forth. David smime.p7s Description: S/MIME cryptographic signature
RE: [PHP-DEV] 5.4 moving forward
From: David Muir [mailto:davidkm...@gmail.com] On 06/06/11 17:48, Tom Samplonius wrote: >> Currently - A lot of ISP's are 'stuck' with PHP5.2 or earlier simply > I don't know if this is really the case. The problem is much larger than most of us would probably like to believe. Some of the major hosts, (like GoDaddy) offer 5.3 as an htaccess swap, but many others don't. For example, Rackspace still hasn't upgraded their Cloud Sites offering and it seems that Bluehost is also still on 5.2.
RE: [PHP-DEV] RFC: Short syntax for Arrays (redux)
On Sat, Jun 4, 2011 at 4:52 AM, David Zülke wrote: > Yes, I know. Then why are you and others demanding that the resulting syntax > be fully compatible with JSON so it could be parsed by other JSON parsers? > That makes no sense at all. A file with just ["foo"] in it won't be > interpreted by PHP; you need at least wrappers and a semicolon, and > then you can't just throw it at another JSON parser anymore. I don't think anyone was asking for this. I and others have been misunderstood on this point, and there seems to be some confusion about how "other systems" came into this discussion. The desire is to be able to copy/paste things back and forth and make it work with only minor tweaks. For example, when debugging a query against a system that uses JSON as the standard for communication, it is invaluable to be able to copy the problem query from your code, paste it into whatever administrative interface you have, and replace any variable rvalues with constants. After the problem has been worked out, you can copy from the admin interface, paste back to the code, and restore any variables. If PHP handles an object/array syntax that is roughly similar to JSON, this becomes easy. The more different the syntaxes are, the more painful this becomes, until eventually it really isn't an option at all (which is where we are now). An example perhaps more familiar to most of us is debugging complex regular expressions. Imagine how impossible this would be if there were no way to copy the regular expression from your code to a web based debugger without rewriting it? Also, consider how frustrating it is sometimes when you paste it back and it still doesn't work, because you forgot to escape your slashes. The more manual translation the programmer has to do, the more impractical these sorts of tools become for debugging. I know a lot of people on this list have strong feelings about whether other systems should be using JSON as a query language/transfer encoding/whatever else; but, the fact is that they do. These systems are growing more popular, and not going to disappear any time soon, which means that like it or not, developers will need tools and languages that simplify the development and debugging process. This RFC should be considered (among other things) in terms of whether it is helpful to developers using these systems, but not in terms of whether anyone wishes these systems would go away (because they won't). John Crenshaw Priacta, Inc. -- 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)
On 2011-06-01, Sean Coates wrote: > > Now, the only reason I would personally support the array shortcut is > > if it was an implementation of JSON. I know that's not on the table > > here > > I don't think anything is officially off the table, unless we forego > discussion. > > My application is largely JSON-powered. We pass data from back- to > front-end via JSON, we interact with MongoDB via the extension (which > is an altered JSON-like protocol (arrays instead of objects), but > would be a lot more fluent with actual objects—they're just too hard > to make in current PHP), and we interface with ElasticSearch. The > paste I linked earlier is our primary ElasticSearch query. > > The benefits of first-class JSON are important and wide-reaching; > especially when interacting with systems like the ones I've mentioned. > There's a huge amount of value in being able to copy JSON out of PHP > and into e.g. CURL to make a query to ElasticSearch without worrying > that I've accidentally nested one level too deep or shallow, or > accidentally mistranslating my arrays into JSON. > > This is not about saving five characters every time I type array(), > it's about making my systems all work together in a way that's a > little less abstracted, and a lot less prone to error. *applause* Well, said, Sean. Basically, this discussion should be likened to adding SimpleXML to PHP -- providing tools that make interoperability with other systems or languages simpler. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- 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)
On 2011-06-01, Michael Shadle wrote: > On Wed, Jun 1, 2011 at 3:09 PM, Sean Coates wrote: > >> This is not about saving five characters every time I type array(), >> it's about making my systems all work together in a way that's a >> little less abstracted, and a lot less prone to error. > > Why not make your data in JSON and then $foo = json_encode($data) ? > > Why try to adopt JSON to PHP, just so it matches another language's > format? > > You do realize adding JavaScript syntax for arrays will only make that > consistent with JavaScript, otherwise you're still coding PHP with PHP > syntax, functions, etc. for everything else. That argument seems moot. > If you're more comfortable with JavaScript, start developing in node > if that is your cup of tea. JavaScript is not the only target here. Many, many APIs are utilizing JSON either internally or as the mechanism for communication with other systems. Additionally, have you worked with complex data structures, and attempted to de/serialize to/from PHP? ext/json does fairly well, but there are many places where it fails, and many gotchas to consider to ensure things are serialized correctly. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
On Mon, Jun 6, 2011 at 7:12 PM, Lester Caine wrote: > Pierre Joye wrote: > >> >>> > http://httpd.apache.org/download.cgi >>> > Win32 Binary IS one of the few binaries Apache supply!!! Some >>> government >>> > sites will ONLY allow that version to be installed:( >>> > PHP5.2 installs have then been approved for use with the official >>> apache >>> > install, so are you saying we need to go back to even earlier builds >>> of >>> > PHP5.2 to work with this? >>> >> I will repeat it a last time here, as I told it too many times >> already, including to you. These binaries are convenience builds and >> are by no mean official builds. That's not my word but the apache's >> guys. >> > > Please can you provide a link where THAT statement is made! > > The download page only makes reference to checking the security of a > download by checking the signatures, and it is this level of security that > is used is a statement that any of the downloads are 'clean' from what ever > mirror source they are downloaded from. There is nothing on > http://apache.favoritelinks.net//httpd/binaries/win32/README.html that > says that the windows builds are anything other than approved distributions > of the current builds of apache. Installation note for WAP have pointed new > users to start with the apache download for MANY years so that is where new > users will always start, and when an update is released, windows users are > redirected once again to the download page. > > you can read more about this here: http://osdir.com/ml/php-windows/2011-04/msg00023.html especially this: http://marc.info/?l=apache-httpd-dev&m=129646769502349&w=2 Tyrael
Re: [PHP-DEV] 5.4 moving forward
On Mon, Jun 6, 2011 at 7:12 PM, Lester Caine wrote: > Please can you provide a link where THAT statement is made! Chech the php windows internals list archive as well as the httpd devel ones. This statement has been written numerous times in both lists. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Object and Array Literals
On Mon, 2011-06-06 at 13:10 -0400, Sean Coates wrote: > > Please add the RFC header so we know what's the status. > > Thanks for catching this. > > >> $a = ['one': 1, 'two': 2, 'three': 'three']; > > > > has anyone played with the parser to > > implement it? > > I have not, personally. I feel like it would be a waste of time at this > point, unless a logical problem can be identified. > > > Also the : syntax was not the preferred one either in > > the short syntax RFC. > > This RFC is a superset of the short array syntax RFC, in my opinion. > > > About the anonymous objects, the usage of stdclass is rare, at least > > for the ones I met or use. > > We use it a lot. This grep is from the root of the Gimme Bar code (my work > project): > > $ grep -ir 'StdClass' * | wc -l > 229 > > > A last comment for the record here, this whole JSON-like syntax sounds > > wrong to me from the beginning. JSON does not aim to be written or > > read by human being. It is about exchanging data between two ends. I > > don't think using it as a base for a syntax in a language is a good > > thing to do. > > You've just stated that you don't use this sort of thing very often (which is > fine, but users who don't use this very often are not my intended target > audience for this RFC). > > In my experience, users who DO interact with systems that speak JSON (or a > JSON-like syntax) find this very useful, and have been wanting it for a long > time. I have anecdotal evidence of this, but I could draw up something more > concrete if that's what is required to get this to pass. > > S > > While I would have been happy with the short array syntax proposed earlier, I do have to say that Sean's points make a lot of sense to me and I am strongly inclined to agree with him. I can't really see any harm in this superset compared to the previous; it seems to me like it would just make a lot of things handier. - M. -- Marcel Esser VP/Engineering, CROSCON Washington, D.C. Office @: marcel.es...@croscon.com office.us +1 (202) 470-6090 mobile.us +1 (202) 250-1988 mobile.de +49 (0)176 391 226 23 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
Pierre Joye wrote: > http://httpd.apache.org/download.cgi > Win32 Binary IS one of the few binaries Apache supply!!! Some government > sites will ONLY allow that version to be installed:( > PHP5.2 installs have then been approved for use with the official apache > install, so are you saying we need to go back to even earlier builds of > PHP5.2 to work with this? I will repeat it a last time here, as I told it too many times already, including to you. These binaries are convenience builds and are by no mean official builds. That's not my word but the apache's guys. Please can you provide a link where THAT statement is made! The download page only makes reference to checking the security of a download by checking the signatures, and it is this level of security that is used is a statement that any of the downloads are 'clean' from what ever mirror source they are downloaded from. There is nothing on http://apache.favoritelinks.net//httpd/binaries/win32/README.html that says that the windows builds are anything other than approved distributions of the current builds of apache. Installation note for WAP have pointed new users to start with the apache download for MANY years so that is where new users will always start, and when an update is released, windows users are redirected once again to the download page. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling "modern" extensions
On Sat, 4 Jun 2011, Andi Gutmans wrote: > For starters I would bundle ext/mongo which is very well maintained; > see if we can get "thrift_protocol" contributed to PECL and included > (support HBase and Cassdandra and used by a few PHP SDKs integrating > with these data stores). I generally agree, but regarding the MongoDB extension I am a bit in doubt. There is a lot of changes (new things, but also bug fixes), and just by having it in PECL it makes it (a bit easier) to update. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Object and Array Literals
> Please add the RFC header so we know what's the status. Thanks for catching this. >> $a = ['one': 1, 'two': 2, 'three': 'three']; > > has anyone played with the parser to > implement it? I have not, personally. I feel like it would be a waste of time at this point, unless a logical problem can be identified. > Also the : syntax was not the preferred one either in > the short syntax RFC. This RFC is a superset of the short array syntax RFC, in my opinion. > About the anonymous objects, the usage of stdclass is rare, at least > for the ones I met or use. We use it a lot. This grep is from the root of the Gimme Bar code (my work project): $ grep -ir 'StdClass' * | wc -l 229 > A last comment for the record here, this whole JSON-like syntax sounds > wrong to me from the beginning. JSON does not aim to be written or > read by human being. It is about exchanging data between two ends. I > don't think using it as a base for a syntax in a language is a good > thing to do. You've just stated that you don't use this sort of thing very often (which is fine, but users who don't use this very often are not my intended target audience for this RFC). In my experience, users who DO interact with systems that speak JSON (or a JSON-like syntax) find this very useful, and have been wanting it for a long time. I have anecdotal evidence of this, but I could draw up something more concrete if that's what is required to get this to pass. S -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling "modern" extensions
On Mon, Jun 6, 2011 at 6:53 PM, Matthew Weier O'Phinney wrote: > My point is that perhaps PHP has missed the boat a bit by moving > everything into extensions. Perhaps if an extension is particularly > popular, it should be incorporated into core. But let USAGE drive that, > not the opinions of individuals on @internals. I cannot disagree than with this statement. PHP is one of the language with the most connectivity solutions, fast adoption of new technologies, etc. Why? Because the language itself is relatively stable while its extensions are created every day for every possible use. However it seems that you forgot to consider what I said here a couple of times already. Having one nosql extension in core won't make hosters make the respective server side infrastructure available. How many hosters provide firebird? DB2? Only sqlserver is part of the standard windows offers but that's due to some different factors. That's why we should differentiate general purposes extensions like pecl's http and driver like mongo. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Object oriented session handlers
Forgot to keep the list on this one. On Mon, Jun 6, 2011 at 11:19 AM, Mike Willbanks wrote: > A while ago I submitted a patch to allow session_set_save_handler() to >> accept a class, and support the inheritance of the default session >> handler's methods. >> >> The RFC has a more detailed description and the current patch: >> https://wiki.php.net/rfc/session-oo >> >> Changes since this was last discussed: >> - More sanity checking to prevent handlers being called in unexpected >> states >> - ZTS fixes >> >> Any thoughts? >> > > Unfortunately the class may cause a BC break due to the naming. Although > namespaces could help in reducing the potential scope of a BC break. > > This is a huge win for those of us with generally highly custom session > handlers. This has been a consistent point of pain and being able to > "extend" rather than reimplement would be a very nice enhancement. > > Now on the new SessionHandler object; is this now utilized by default? I > seen the wrapper in the patch but it seems like we utilize all of the > existing code with modifications to also utilize an object? Should > the procedural way be deprecated at some point or is the plan to support > both styles? > > Regards, > > Mike > >
Re: [PHP-DEV] Bundling "modern" extensions
On 2011-06-05, Pierre Joye wrote: > It sounds like persons doing these inquiries do not know PHP, its > environment and how it works, neither they know that 99% of the linux > distribution (and in some extend on windows too) provide most of the > modern extensions with their standard distribution. I disagree. Most distributions have a stock install that offers _less_ than a vanilla PHP install, and anything else has to be installed via the system's package manager, or via PECL (assuming you have the rights to install pecl extensions in the first place). So, while they may OFFER them, they're not available BY DEFAULT. > For general purposes extensions or really globally useful (as any > almost all php users will have a use), PHP's rapid rise in popularity initially was because it DID bundle the kitchen sink, and more, by default. Why was MySQL so popular with PHP in the early days (and still!)? Because it was available by default. Why are so many folks still not using an opcode cache, despite people saying for close to a decade that it should be the first stop towards improving performance? Because PHP has _never_ bundled one by default. Why is JSON so ubiquitous for interacting with PHP services? Because it's available by default. My point is that perhaps PHP has missed the boat a bit by moving everything into extensions. Perhaps if an extension is particularly popular, it should be incorporated into core. But let USAGE drive that, not the opinions of individuals on @internals. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling "modern" extensions
On 2011-06-05, Pierre Joye wrote: > On Sun, Jun 5, 2011 at 1:09 PM, Hannes Magnusson > wrote: > > > I can't think of a statement I would disagree more with. These are > > exactly the ones we should be bundling. > > > > My reasoning is simple. The key for bundling extensions is to have > > > them available for most hosting solutions. If a shared host provides > > > > No. Join the real world again. Anything not in vanilla PHP is hard to > > install because it causes more work in maintenance of the server, and > > increases the risk of fuckups etc etc > > Can you please stay at a technical level? Thanks. I'm not going to > argue if my experiences, feedbacks and interactions with any kind of > projects is larger or longer than yours (it is as a matter of fact but > who cares?). > > But one thing is sure, all distributions do include mongodb, > memcache(d), couchdb, etc. If you can't run an apt-get install > memcached (non core), just like you run apt-get install pdo_mysql > (core), then there is something intrinsically wrong in your system. Or it means YOU DO NOT HAVE ROOT. Just because the distributions OFFER the extensions does not mean that users have ACCESS to them. Not everyone has complete control over their boxes, or sysadmins who are willing to update configurations. If the functionality were available as part of core, developers would simply have access, regardless of distribution and permissions. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
On Mon, Jun 6, 2011 at 6:48 PM, Lester Caine wrote: > > http://httpd.apache.org/download.cgi > Win32 Binary IS one of the few binaries Apache supply!!! Some government > sites will ONLY allow that version to be installed :( > PHP5.2 installs have then been approved for use with the official apache > install, so are you saying we need to go back to even earlier builds of > PHP5.2 to work with this? I will repeat it a last time here, as I told it too many times already, including to you. These binaries are convenience builds and are by no mean official builds. That's not my word but the apache's guys. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
Hi! Currently off the shelf, 5.2.17 is the 'old stable' but for some windows users it IS the only available version. Changing the rest of the infrastructure to 5.2.17 is unsupported. It is announced on php.net. Now, some Windows users, due to certain choices, may have to run this version - but this doesn't change the fact it's officially unsupported. So I don't see how it supports viability of LTS idea. package! So while PHP may have washed it's hands of the problem, those users who are stuck in the hole still need to be supported in some way. But all that is There's nothing to prevent anybody willing to do it from providing this support. However, the question is not if there are users with some special needs. The question is LTS, specifically: 1. Will PHP group ever willing to support a version in LTS timeframe - so far it never happened 2. How we know we'd need to support such version UPFRONT - before it's released? being asked for is security fixes which seem to be a LOT less of a problem nowadays anyway? So support IS just a matter of maintaining availability to it and the correct builds of extensions that go with it. It looks to me you are confusing the question of "is LTS a viable model for PHP development" with "if we had LTS 5 years ago, would somebody benefit from it now". These are two different questions, and the second one is pure theoretical since we didn't and still haven't and I for one still don't understand how we could have it. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
Pierre Joye wrote: *WE* recommend using Apachelounge builds of apache, but some sites simply > will not use that as it is not the recommended build from Apache. They > religiously follow the rules printed on the official distributions and the > download page is an official document as far as they are concerned, so they > are being told to use VC6 builds. Apachelounge is not considered an official > apache site:( There is no official binaries for apache, please understand once and for all and get over it. Apachelounge are well trusted builds using a modern compilers and the offical Apache sources. http://httpd.apache.org/download.cgi Win32 Binary IS one of the few binaries Apache supply!!! Some government sites will ONLY allow that version to be installed :( PHP5.2 installs have then been approved for use with the official apache install, so are you saying we need to go back to even earlier builds of PHP5.2 to work with this? > If the situation has now changed where is this documented? "Do*NOT* use VC9 > version with apache.org binaries" is very clearly stated on the download > page. And that's still true. But that has nothing to do with Apache or PHP being not stable but CRT compatibilities. In any case, if you find any bug, please report them at bugs.php.net, but that's totally unrelated to this thread. See point above ... with the current windows situation on windows.php.net, PHP5.2.17 is the last version of php available to go with the official windows binaries from Apache? TESTING PHP5.3 on an official apache build and reporting bugs is not the problem here, since users are told not to use them at all. Since official apache builds have always worked stably for years with an 'official' build of PHP people simply expect that to continue! -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Object and Array Literals
hi Sean, Please add the RFC header so we know what's the status. Some comments: > $a = [1,2,'three']; I liked the existing RFC (https://wiki.php.net/rfc/shortsyntaxforarrays) so I indeed like it here too. > $a = ['one': 1, 'two': 2, 'three': 'three']; -1, did not like before, I still do not like it :) It will certainly create some confusions and does not bring a lot of benefits. I'm not sure how it will work either with a possible support of named arguments. Last but not least, has anyone played with the parser to implement it? Also the : syntax was not the preferred one either in the short syntax RFC. About the anonymous objects, the usage of stdclass is rare, at least for the ones I met or use. I'm not sure about the interoperability argument as conversions will still happen, so as someone else said, it looks familiar but has in my opinion nothing to do with interoperability. I'd to say a temporary -1. Something that can change my mind is the ability to initialize an object and its property using a similar syntax, but it sounds tricky or not too useful (getter/setter a la c# sounds much useful for example, if we need something in this area). A last comment for the record here, this whole JSON-like syntax sounds wrong to me from the beginning. JSON does not aim to be written or read by human being. It is about exchanging data between two ends. I don't think using it as a base for a syntax in a language is a good thing to do. On Sun, Jun 5, 2011 at 3:30 AM, Sean Coates wrote: > Hello. > > I've posted a RFC concerning Object and Array Literals on the wiki: > https://wiki.php.net/rfc/objectarrayliterals > > Please read, and if you have a comment that is not already covered in the > RFC, raise it here. I'm definitely open to discussion, but I would really > love to keep this discussion civil. > > To get the ball rolling, here are a few points that I think we need to > discuss: > > • Strictness of unquoted keys. > • Support => in addition to : as a key:value separator. > • possibility of simply not supporting the \u### syntax for Unicode > characters in literal strings (just like the rest of PHP). > • Should mixed-format (numeric and associative arrays) be allowed? > (e.g. [1,'two':2, 3]) > > I beg you to keep name-calling, conclusion-jumping, and general hostility out > of this thread. Thanks for your attention. > > S > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PATCH] Notice on array to string convertion
On Mon, 2011-06-06 at 12:32 -0400, Matthew Weier O'Phinney wrote: > On 2011-06-06, Ferenc Kovacs wrote: > > --00261883a59c62fbe404a50bd89c > > Content-Type: text/plain; charset=UTF-8 > > > > On Mon, Jun 6, 2011 at 3:36 PM, Matthew Weier O'Phinney < > > weierophin...@php.net> wrote: > > > > > On 2011-06-02, Patrick ALLAERT wrote: > > > > I would like to introduce an E_NOTICE when an array is silently > > > > converted to a string. > > > > This isn't very useful as it constantly produces the following string: > > > > "Array" and in most of the case, this is a sign of an error. > > > > > > > > Let me know about your feelings. > > > > > > +1 (for E_NOTICE) > > > > > > This allows warning folks easily during development of potential issues, > > > and for those of us using tools like PHPUnit, we'll catch the problem > > > early. At the same time, it doesn't break existing code. > > > > > > > > I'm curious, why do you think that E_WARNING would break existing code? > > I didn't mean to imply E_WARNING would break existing code. However, > I've often seen error handlers that break execution on E_WARNING and > above -- and I'm not 100% convinced that this would be a situation > warranting a warning. It "feels" more akin to a notice from accessing an > unset array key. Either way, however, if I'm using PHPUnit, I'll be > notified. :) > > > the only think that I can come up with, that some people runs with > > display_errors = On, and they doesn't mask E_WARNINGs with > > error_reporting. I think that this would be more reason to use > > E_WARNING there, else those people won't get noticed about this > > problem. > > I personally run E_ALL | E_STRICT, so I catch either -- and log when in > production. As noted, it's personal preference. I'm okay with either > flag, to be honest. > > -- > Matthew Weier O'Phinney > Project Lead| matt...@zend.com > Zend Framework | http://framework.zend.com/ > PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc > I get the feeling that the choice between the two flags is much more a question of how much of a sin they are, and much less a question of their functional difference. In this instance, at least. - M. -- Marcel Esser VP/Engineering, CROSCON Washington, D.C. Office @: marcel.es...@croscon.com office.us +1 (202) 470-6090 mobile.us +1 (202) 250-1988 mobile.de +49 (0)176 391 226 23 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PATCH] Notice on array to string convertion
On 2011-06-06, Ferenc Kovacs wrote: > --00261883a59c62fbe404a50bd89c > Content-Type: text/plain; charset=UTF-8 > > On Mon, Jun 6, 2011 at 3:36 PM, Matthew Weier O'Phinney < > weierophin...@php.net> wrote: > > > On 2011-06-02, Patrick ALLAERT wrote: > > > I would like to introduce an E_NOTICE when an array is silently > > > converted to a string. > > > This isn't very useful as it constantly produces the following string: > > > "Array" and in most of the case, this is a sign of an error. > > > > > > Let me know about your feelings. > > > > +1 (for E_NOTICE) > > > > This allows warning folks easily during development of potential issues, > > and for those of us using tools like PHPUnit, we'll catch the problem > > early. At the same time, it doesn't break existing code. > > > > > I'm curious, why do you think that E_WARNING would break existing code? I didn't mean to imply E_WARNING would break existing code. However, I've often seen error handlers that break execution on E_WARNING and above -- and I'm not 100% convinced that this would be a situation warranting a warning. It "feels" more akin to a notice from accessing an unset array key. Either way, however, if I'm using PHPUnit, I'll be notified. :) > the only think that I can come up with, that some people runs with > display_errors = On, and they doesn't mask E_WARNINGs with > error_reporting. I think that this would be more reason to use > E_WARNING there, else those people won't get noticed about this > problem. I personally run E_ALL | E_STRICT, so I catch either -- and log when in production. As noted, it's personal preference. I'm okay with either flag, to be honest. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Voting Process (was: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward))
On 2011-06-05, Zeev Suraski wrote: > I'm fine if the entire 'Feature selection and development' part goes > out of the RFC, but if there's any reference to how features are > determined, we'd better get it right. > > Making changes once we've approved this RFC is going to be much > tougher. This is big stuff - it's no coincidence we didn't have such > guidelines for almost 15 years. > > Honestly there are other parts about the voting process that are much > hotter potatoes than the points I brought up - such as who gets to > vote, This is a tough one. I'm typically in favor of having the vote be completely open to anybody. However, since we're talking language features, there are a lot of other considerations -- internals folks will have a much better idea of what the BC and support ramifications are. Perhaps two votes should be considered? A "general population" vote, and an "internals" vote? This would show discrepancies between what users of PHP want, and how internals is voting. If internals votes against a feature that the general population has approved, I would expect to see some sort of "executive summary" showing what technical issues are at play that led to the internals vote. This would serve as a good historical record -- and also potentially show where bias lies within the internals community. > is 50%+1 enough or do we need stronger majorities for substantial > language changes (67%/75%), I think anything less than a strong majority (2/3 or 3/4) often is indicative of either ambivalence or strongly competing ideas. The question is where that threshold should be set (I'd lean towards 2/3 vote.) > can someone who failed passing an RFC just put it up for another vote > right away or is there some sort of a cool-off period, I'd argue a 2-3 week period in which to re-work the proposal and incorporate feedback from the prior discussion/voting periods. > etc. etc. I think all of these need to be answered before we let this > RFC govern how we do feature definition. > > Zeev > > > -Original Message- > > From: Stas Malyshev [mailto:smalys...@sugarcrm.com] > > Sent: Sunday, June 05, 2011 11:17 PM > > To: Zeev Suraski > > Cc: Pierre Joye; PHP Internals > > Subject: Re: Voting Process (was: [PHP-DEV] Re: Voting does not belong on > > the wiki! (Was: [PHP-DEV] 5.4 moving forward)) > > > > Hi! > > > > > I'd still like to hear from others what they think about my > > > proposal. I'd like to update the Release Process RFC with these > > > suggestions if people like them. > > > > I think these voting process additions totally make sense. But I am > > not sure it makes sense to put everything in one release RFC. The > > reason for that is that we don't want to endlessly amend and improve > > the RFC without having it actually agreed upon, I would rather > > prefer to agree on what we agree, have it as base for the future and > > then add other stuff. I've noticed a tendency on the list to lose > > the major goal behind endless amendments and tweaks and not doing > > what we agree on because we disagree on some minor detail. So maybe > > it would make sense to have release RFC separate (without spelling > > out the voting process there) and voting RFC separate which would > > define the voting process? -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $arr = array('Hello', 'world'); $arr();
On 2011-06-06, Hannes Magnusson wrote:
> On Sun, Jun 5, 2011 at 17:52, Felipe Pena wrote:
> > Reading our bug tracker I noticed a good feature request [1] from 2009 which
> > points to an interesting feature that I think makes sense for us, since we
> > are now working with $f() using objects and strings, and the array('class',
> > 'method') is an old known for call_user_func()-like functions.
>
> I like it.
>
> I also think we should implement "callable" typehint.
> A lot of framworks are now adopting Closure as a typehint for that,
> which is annoying due to the fact you have to wrap anything else in a
> closure just to pass that typehint.
Agreed. It's even more problematic because the manual clearly states
that the "Closure" class is considered an implementation detail, and
should not be relied upon. As such, if the implementation changes in the
future, all those frameworks/libraries will need to refactor.
And for those that try to do it "right," they need to jump through a
fair bit of logic (test for object or string, test for array) in order
to hand off execution properly.
> Essentially the callable typehint would be the same as
> is_callable($arg, true);
>
> That means I can pass in any string with a function name, an array
> (with class+methodname), and a closure.
+1.
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Object oriented session handlers
On 3 June 2011 02:18, Arpad Ray wrote: > Hi, > > A while ago I submitted a patch to allow session_set_save_handler() to > accept a class, and support the inheritance of the default session > handler's methods. > > The RFC has a more detailed description and the current patch: > https://wiki.php.net/rfc/session-oo > > Changes since this was last discussed: > - More sanity checking to prevent handlers being called in unexpected states > - ZTS fixes > > Any thoughts? > > Regards, > > Arpad Not an internals expert, but I do have a question. When would the session handler object be destroyed? If sessions are being logged to a DB (maybe via a userland PHP class), is internal reference counting enough to handle the order of destruction? If the DB connection is destroyed before the session handler gets it destructor called (or the session_write_close equivalent), the session won't be able to log the data and there would be no warning to the client as engine is in auto tidy up mode. Obviously, if the developer takes care and calls the destructors in the right order, then everything will be OK, but this is not something I see very often. What about circular references and interdependent references? -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling "modern" extensions
On Mon, Jun 6, 2011 at 5:18 PM, Larry Garfield wrote: > For me the question isn't "should we bundle memcached in PHP core", it's > "how do we establish an expected baseline of PHP components that developers > can reasonably expect will be available, and what should be in that?" Right > now, that baseline is "bundled in core". Having memcached, mongodb or whatever other similar extensions in core won't make these hosters provide memcache or mongodb support, not the waste majority. However there are already hosters providing mongodb or couchdb support and they all take care of the respective extensions using the non core modules (pecl or github). That's why I really like to differentiate sqlite/http and similar extensions from extensions being a client for a given server or service. Mysql is still a de facto standard but that's something we cannot really compare to any of the current nosql&co technologies, from a usage or spread point of view. Dedicated hosting are usually the place where they are used (virtualized or not). Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
On Mon, Jun 6, 2011 at 6:12 PM, Lester Caine wrote: > Pierre Joye wrote: >> >> We use apache and 5.3 smoothly and with the recent addition of rwlock >> in apc on windows, it runs even better and faster. >> >> I'm sorry but unless you provide bugs report with clear reproduce >> where we can actually try to help you, there is no chance to get >> anywhere with this kind of discussions. >> >> Now I would suggest to use bugs.php.net to report any issue you have >> on apache on windows with PHP. > > Does that include reporting windows.php.net pages? > http://windows.php.net/download/ at the present time this is very clearly > directing users that they have to use VC6 builds for Apache and they are > only provided for PHP5.2.17 > > *WE* recommend using Apachelounge builds of apache, but some sites simply > will not use that as it is not the recommended build from Apache. They > religiously follow the rules printed on the official distributions and the > download page is an official document as far as they are concerned, so they > are being told to use VC6 builds. Apachelounge is not considered an official > apache site :( There is no official binaries for apache, please understand once and for all and get over it. Apachelounge are well trusted builds using a modern compilers and the offical Apache sources. > If the situation has now changed where is this documented? "Do *NOT* use VC9 > version with apache.org binaries" is very clearly stated on the download > page. And that's still true. But that has nothing to do with Apache or PHP being not stable but CRT compatibilities. In any case, if you find any bug, please report them at bugs.php.net, but that's totally unrelated to this thread. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
Pierre Joye wrote: We use apache and 5.3 smoothly and with the recent addition of rwlock in apc on windows, it runs even better and faster. I'm sorry but unless you provide bugs report with clear reproduce where we can actually try to help you, there is no chance to get anywhere with this kind of discussions. Now I would suggest to use bugs.php.net to report any issue you have on apache on windows with PHP. Does that include reporting windows.php.net pages? http://windows.php.net/download/ at the present time this is very clearly directing users that they have to use VC6 builds for Apache and they are only provided for PHP5.2.17 *WE* recommend using Apachelounge builds of apache, but some sites simply will not use that as it is not the recommended build from Apache. They religiously follow the rules printed on the official distributions and the download page is an official document as far as they are concerned, so they are being told to use VC6 builds. Apachelounge is not considered an official apache site :( If the situation has now changed where is this documented? "Do *NOT* use VC9 version with apache.org binaries" is very clearly stated on the download page. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: RFC: Enum
On 2011-06-03, Dennis Haarbrink wrote:
> One thing I would really like to see in 5.4 is enums.
> There is already an RFC for that: https://wiki.php.net/rfc/enum
>
> This was discussed in february this year, but no consensus was reached.
> IIRC, the most notable problems were:
> - What is the 'value' of enum constant: string or int, user defined scalar,
> defaults
> - Ability to make enums more 'class like', some people wanted to be able to
> add methods.
>
> Another thing which was discussed (and I think most people agreed on that),
> but is not in the RFC: type hinting in method signatures.
I'd like to see some examples of _using_ the enums -- how do you
reference them? How do you make comparisons against them? As an example:
if (!$value in SomeEnum) {
throw new Exception;
}
Would that work? or are you envisioning this:
if (!$value instanceof SomeEnum) {
throw new Exception;
}
(The latter is less intuitive, IMO).
One particular use case I'm curious about: could comparisons take into
consideration logical operators (&, |, ^, etc.)?
Comparison and/or type hinting against an enum is really the only
feature I see that makes them worthwhile; otherwise, we already have
namespaced and class-level constants.
> I think we should keep this simple proposal simple, let it be an enum in all
> its simplicity.
> The toughest part would be to decide what would be the default value. Some
> proposed to use the name of the constant, which is imho best for
> debuggability (i like this one the best), or an auto incrementing int,
> saying that it is better performance wise and which is more analog with
> mysql's enum type.
>
>
> So, to sum up:
> - Do we really need enum level methods?
> - Need to reach consensus on default values (strings vs auto inc. ints)
> - RFC needs to be updated, explaining the type hinting of enums in method
> signatures
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling "modern" extensions
On Mon, 2011-06-06 at 10:18 -0500, Larry Garfield wrote:
> The only way, currently, that projects can predict what a given host
> will have installed is "bundled in core PHP". If it's in the core PHP
> bundle, we can *usually* expect it to be there. If not, we can
> *usually* presume it won't be. That's not a hard and fast rule, but
> it's the best we've got right now.
While that rule is not true by far.
Shared hosting usually does not offer com_dotnet, gettext, interbase,
ldap, mssql, oci8, odbc, pdo_dblib, pdo_firebird, pdo_oci, pdo_odbc,
pdo_pgsql, pgsql, recode, snmp, sybase_ct
I know many which don't provide ftp, gmp, imap, mbstring, openssl, phar,
shmop, sysvmsg, sysvsem, sysvshm, wddx, xmlrpx, zip, zlib
Sometimes for good reasons (a firebird extension makes no sense if you
don't provide firebird) sometimes for strange reasons ("i don't want my
customers to waste CPU/network") so in the end bundling is no guarantee.
and btw. I also now shared hosters which offer PECL stuff after
customers demanded it.
Unless we start a certification program ("PHP Certified Hoster" ..
demanding some specific features etc.) there's little we can do. And I
doubt we want to do that ;-)
So the guessing game is hard.
what I started some years ago was collecting some statistics which is
reported by installers from PHP applications. The first app I'm using
this with is phpMyFAQ, but phpBB3 meanwhile has a similar feature. By
these statistics I can tell that just 1.5% of the people installing
phpMyFAQ are having APC installed, Zend Optimizer is available more
often, 65.7%. 98.7% have the tokenizer extension enabled. Roughly 3/4
are claiming to use hosting companies. (all only counting where users
agreed to send the information, collecting since June 2007, while the
collection logic was broken for a few months now ...)
One day[tm] I plan to make all this data public with a simple query
interface.
I'd also be interested in adding such a data collection to other
software. If you're interested feel free to contact me of list.
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: $arr = array('Hello', 'world'); $arr();
On 2011-06-05, Felipe Pena wrote:
> Reading our bug tracker I noticed a good feature request [1] from 2009
> which points to an interesting feature that I think makes sense for
> us, since we are now working with $f() using objects and strings, and
> the array('class', 'method') is an old known for call_user_func()-like
> functions.
>
> So, I wrote a patch [2] that allow such behavior to be consistent with
> arrays. See some examples:
>
> class Hello {
>public function world($x) {
> echo "Hello, $x\n"; return $this;
>}
> }
>
> $f = array('Hello','world');
> var_dump($f('you'));
>
> $f = array(new Hello, 'foo');
> $f();
>
> All such calls match with the call_user_func() behavior related to
> magic methods, static & non-static methods.
>
> The array to be a valid callback should be a 2-element array, and it
> must be for the first element object/string and for the second string
> only. (just like our zend_is_callable() check and opcodes related to
> init call)
>
> Any thoughts?
Huge +1 from me -- having to do constructs like the following have been
a huge headache for me:
if (is_callable($callback)) {
if (is_object($callback) || is_string($callback)) {
return $callback($arg);
}
return call_user_func($callback, $arg)
}
This would simplify that tremendously:
if (is_callable($callback)) {
return $callback($arg);
}
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [RFC] Object oriented session handlers
On 2011-06-03, Arpad Ray wrote: > A while ago I submitted a patch to allow session_set_save_handler() to > accept a class, and support the inheritance of the default session > handler's methods. > > The RFC has a more detailed description and the current patch: > https://wiki.php.net/rfc/session-oo > > Changes since this was last discussed: > - More sanity checking to prevent handlers being called in unexpected states > - ZTS fixes > > Any thoughts? Makes sense to me, and quite straight-forward in purpose. Can't comment on the patch, though. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Supporting Binary Notation for Integers
On Tue, Nov 30, 2010 at 10:43 AM, Pierre Joye wrote: > +1, next major version. > Just following up on this patch from Nov 2010. Has there been any movement on this? As it's not committed, I was just wondering what the next major version would be PHP 5.4, 6, ? As always, I'm happy to provide patch updates/modifications on request. Thank you for your time! -- Jonah H. Harris Blog: http://www.oracle-internals.com/
Re: [PHP-DEV] Bundling "modern" extensions
On Mon, Jun 6, 2011 at 5:18 PM, Larry Garfield wrote: > On 6/5/11 7:54 AM, Ferenc Kovacs wrote: > > just for the record, I agree with Pierre on this one. >> our userbase has two distinct group: those who are using shared hosting >> and >> usually use some third party cms or write their own crappy suboptimal >> code, >> and those who use php to build bleeding edge custom product (either on top >> of some 3rd party framework, or on their own). >> for the first group, they doesn't configure their installation, but their >> hosting providers do that for them. >> those providers usually has custom configuration or compilation of php, >> because by default, there are many ways where one user in the shared >> environment can blow up or compromise the full server. >> so for those people, including more stuff in the core means change, which >> they have to adapt, and migrate (add more disable_ to the vhost configs or >> recompile php without the newly included stuff). >> btw. usually the general cms solutions targets the standard installations, >> so they won't use stuff like mongodb. at least not as a requirement in >> their >> core functionalities. >> > > As someone who deals mostly with managed hosting (not necessarily "shared" > but a server where the customer doesn't have root), that's an important > consideration. For anyone working in the non-custom CMS world (Drupal, WP, > Joomla, etc.), knowing the baseline you can expect from a general PHP host > is critically important. Drupal, for instance, considered but rejected > making SQLite a requirement for Drupal 7 for some low-level bootstrapping > logic because we found a few hosts that we did want to continue to support > that didn't bundle it. > > The only way, currently, that projects can predict what a given host will > have installed is "bundled in core PHP". If it's in the core PHP bundle, we > can *usually* expect it to be there. If not, we can *usually* presume it > won't be. That's not a hard and fast rule, but it's the best we've got > right now. > > For me the question isn't "should we bundle memcached in PHP core", it's > "how do we establish an expected baseline of PHP components that developers > can reasonably expect will be available, and what should be in that?" Right > now, that baseline is "bundled in core". > > This question is completely irrelevant to people who always have root on > their dev and production servers, but they are, frankly, a minority of > PHP-using domains out there. For those who deal in the mass-market, knowing > that baseline is critical. > > So how do we establish that baseline if not by bundling an extension in > core? > > the "in core" can mean different things. as I mentioned before, the distributors package the php stuff on their own way. so for example debian packages curl, gd, imap, intl, ldap, mysql separately when we have this in "core", and they also have common pecl modules as php packages. event stuff like mysql isn't enabled by default for example, obviously almost every hosting provider will install that. Tyrael
Re: [PHP-DEV] Bundling "modern" extensions
On 6/5/11 7:54 AM, Ferenc Kovacs wrote: just for the record, I agree with Pierre on this one. our userbase has two distinct group: those who are using shared hosting and usually use some third party cms or write their own crappy suboptimal code, and those who use php to build bleeding edge custom product (either on top of some 3rd party framework, or on their own). for the first group, they doesn't configure their installation, but their hosting providers do that for them. those providers usually has custom configuration or compilation of php, because by default, there are many ways where one user in the shared environment can blow up or compromise the full server. so for those people, including more stuff in the core means change, which they have to adapt, and migrate (add more disable_ to the vhost configs or recompile php without the newly included stuff). btw. usually the general cms solutions targets the standard installations, so they won't use stuff like mongodb. at least not as a requirement in their core functionalities. As someone who deals mostly with managed hosting (not necessarily "shared" but a server where the customer doesn't have root), that's an important consideration. For anyone working in the non-custom CMS world (Drupal, WP, Joomla, etc.), knowing the baseline you can expect from a general PHP host is critically important. Drupal, for instance, considered but rejected making SQLite a requirement for Drupal 7 for some low-level bootstrapping logic because we found a few hosts that we did want to continue to support that didn't bundle it. The only way, currently, that projects can predict what a given host will have installed is "bundled in core PHP". If it's in the core PHP bundle, we can *usually* expect it to be there. If not, we can *usually* presume it won't be. That's not a hard and fast rule, but it's the best we've got right now. For me the question isn't "should we bundle memcached in PHP core", it's "how do we establish an expected baseline of PHP components that developers can reasonably expect will be available, and what should be in that?" Right now, that baseline is "bundled in core". This question is completely irrelevant to people who always have root on their dev and production servers, but they are, frankly, a minority of PHP-using domains out there. For those who deal in the mass-market, knowing that baseline is critical. So how do we establish that baseline if not by bundling an extension in core? --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Object and Array Literals
> Can you provide an use case and code example of how that would look?
Sure.
Here's how an ElasticSearch query currently looks in PHP:
$esQuery = new \StdClass;
$esQuery->query = new \StdClass;
$esQuery->query->term = new \StdClass;
$esQuery->query->term->name = 'beer';
$esQuery->size = 1;
// OR
$esQuery = (object)array(
"query" => (object)array(
"term" => (object)array(
"name" => "beer"
)
),
"size" => 1
);
…and here's how it could look with the proposed syntax:
http://localhost:9200/gimmebar/assets/_search?pretty=1 -d'{
> "query" : {
> "term" : {
> "name": "beer"
> }
> },
> "size" : 1
> }'
Even considering the `(object)array(` syntax, it's much easier to work with an
external query (as shown with curl), if we have a (nearly) JSON-compatible
syntax in PHP.
Note that I *could* have written the PHP definition of $esQuery with the
proposed syntax and non-JSON compatible syntax (single quotes, for example),
but I chose to write it with double quotes because I knew I might also want to
pass it to curl.
Realistically, "beer" would be in a variable (maybe `{"term": {"name":
$term}}`), but replacing just the variables is certainly much easier than
translating the `new \StdClass` syntax.
The argument for right-hand-side assignments being allowed in the proposed
syntax (such as in `{'time': time()}`) is still valid because I expect this
syntax will be used both for interoperating with third party services (as
above), but also generally for object and array creation without a care about
third parties.
S
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Patch] GeoIP Tests
hi, please use pecl-dev to talk about pecl's packages. Thanks for your work! On Mon, Jun 6, 2011 at 4:37 PM, Mike Willbanks wrote: > I've gone through the GeoIP extension and ensured all of the tests now pass. > > Bug Report: http://pecl.php.net/bugs/bug.php?id=22749 > Patch File: http://blog.digitalstruct.com/patches/geoip-svn-tests.patch.txt > > Also, it looks like the GeoIP extension is based on an extremely old > version, I am going to start looking to update this to get all of the new > constants that should exist into the extension. > A slight amount of behavior changed and should have been noted previously > for the test as "CA" is no longer a valid country code w/o a region in the > timeZone.c area of the GeoIP C API. > > Someone with karma want to review and apply the patch for the tests? > > Regards, > > Mike > -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [Patch] GeoIP Tests
I've gone through the GeoIP extension and ensured all of the tests now pass. Bug Report: http://pecl.php.net/bugs/bug.php?id=22749 Patch File: http://blog.digitalstruct.com/patches/geoip-svn-tests.patch.txt Also, it looks like the GeoIP extension is based on an extremely old version, I am going to start looking to update this to get all of the new constants that should exist into the extension. A slight amount of behavior changed and should have been noted previously for the test as "CA" is no longer a valid country code w/o a region in the timeZone.c area of the GeoIP C API. Someone with karma want to review and apply the patch for the tests? Regards, Mike
Re: [PHP-DEV] $arr = array('Hello', 'world'); $arr();
On Sun, Jun 5, 2011 at 17:52, Felipe Pena wrote:
> Hi all,
> Reading our bug tracker I noticed a good feature request [1] from 2009 which
> points to an interesting feature that I think makes sense for us, since we
> are now working with $f() using objects and strings, and the array('class',
> 'method') is an old known for call_user_func()-like functions.
I like it.
I also think we should implement "callable" typehint.
A lot of framworks are now adopting Closure as a typehint for that,
which is annoying due to the fact you have to wrap anything else in a
closure just to pass that typehint.
Essentially the callable typehint would be the same as is_callable($arg, true);
That means I can pass in any string with a function name, an array
(with class+methodname), and a closure.
-Hannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
On Mon, Jun 6, 2011 at 3:31 PM, Lester Caine wrote: > Pierre Joye wrote: >>> >>> If you can convince the IT departments of some of the archaic council >>> sites >>> > I am having to deal with that they do not have to stress test every >>> > part of >>> > a new system ... It's exactly the same argument FROM them as you are >>> > giving >>> > below as to why we should NOT provide support! >>> > Fortunately the problem is being eased by the replacement of the >>> > legacy >>> > windows systems with Linux servers but that is still slow going in >>> > some >>> > customer sites. >> >> There is zero difference, windows or linux does not matter at the >> language level. If they don't want to migrate to 5.3, win or linux >> does not matter. >> >> Anyway, that's off topic:) > > What makes you say that - has PHP5.3 suddenly started working with > production releases of Apache on windows? Some site will not use third party > builds which is the WHOLE problem of PHP5.3 on windows ... only PHP5.2 is > available to run with a stock install of Apache. Lester, We use apache and 5.3 smoothly and with the recent addition of rwlock in apc on windows, it runs even better and faster. I'm sorry but unless you provide bugs report with clear reproduce where we can actually try to help you, there is no chance to get anywhere with this kind of discussions. Now I would suggest to use bugs.php.net to report any issue you have on apache on windows with PHP. -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Object and Array Literals
On Mon, Jun 6, 2011 at 8:48 AM, Sean Coates wrote:
>
> I was careful in the RFC to indicate that this is *not* JSON, but if others
> feel as strongly as you do about the use of this term, I think it can be
> removed without hurting the idea (as you indicated).
>
Still, it is mentioned so many times that it could be unintentionally
misleading IMHO.
>
> You're right that the RFC does not declare a syntax that will always
> validate as JSON, nor does it respect serialization rules, but I see it more
> as a declaration syntax than a serialization format, as it is proposed. The
> real goal is to improve interaction with third parties, which I think the
> proposed syntax would allow.
>
> That said, other than the \u syntax, I believe that the proposed
> declaration syntax would still allow JSON from a third party to me
> interpreted by PHP, in a way that makes sense in PHP.
>
Can you provide an use case and code example of how that would look?
>
> > Somewhat on a side note, I do not understand the statement that
> >
> >"using a strict syntax would not conform with the PHP way"
> >
> > or at least how it relates to this RFC.
>
> This is directly related to the JSON-non-strictness that everyone seems to
> want (me included). For example the following is completely invalid in JSON,
> but normally OK (for small values of OK) in PHP:
>
> (not-)JSON: {foo: 1}
> (not-)JSON: {'foo': 1}
> PHP: array(foo => 1)
> PHP: array('foo' => 1)
>
> (For anyone who doesn't follow, correct way in JSON is to use " not '.)
>
> Thanks for the comments.
>
As mentioned earlier, I think the resemblance to JSON is just a happy
coincidence, the syntax makes enough sense by itself. You can argument that
its familiarity/friendliness/ubiquity makes it a good option, but in its
current state (i.e. not defining why JSON compatibility is justified) I'd
say it is not complete.
Regards,
David
Re: [PHP-DEV] Re: [PATCH] Notice on array to string convertion
On Mon, Jun 6, 2011 at 3:36 PM, Matthew Weier O'Phinney < weierophin...@php.net> wrote: > On 2011-06-02, Patrick ALLAERT wrote: > > I would like to introduce an E_NOTICE when an array is silently > > converted to a string. > > This isn't very useful as it constantly produces the following string: > > "Array" and in most of the case, this is a sign of an error. > > > > Let me know about your feelings. > > +1 (for E_NOTICE) > > This allows warning folks easily during development of potential issues, > and for those of us using tools like PHPUnit, we'll catch the problem > early. At the same time, it doesn't break existing code. > > I'm curious, why do you think that E_WARNING would break existing code? the only think that I can come up with, that some people runs with display_errors = On, and they doesn't mask E_WARNINGs with error_reporting. I think that this would be more reason to use E_WARNING there, else those people won't get noticed about this problem. Tyrael
Re: [PHP-DEV] 5.4 moving forward
On 06/06/11 07:27, Stas Malyshev wrote: > Hi! > >> On 2011-06-05, Pierre Joye wrote: >>> On Sun, Jun 5, 2011 at 5:52 PM, Philip Olson >>> wrote: > I'd to say that I'm very happy to finally see such discussions > happening, let sort the base (99% is done by our existing RFC about > release process, let adopt it already!) and move on with 5.4. This is a prime example of what we're talking about. Several have expressed a desire to follow an Ubuntu style of branching instead of the style proposed in said RFC. This is a core issue, so the RFC is certainly not ready to adopt. So does this require a new RFC, or do the RFC proposers feel this is a key concept? > > I think that this RFC does not contain Ubuntu-style LTS and it doesn't > look like it's author(s) support it, so it should be some different > point, which may be RFCed and voted on if we see substantial support > for it. > > Speaking of which, I personally don't understand how LTS thing would > work in PHP. Does it mean we'd decide out of the blue that some > version would have extended support, upfront? Like, say, we now say > "5.5 would have extended support"? Why would we want to do this, how > would we know it? E.g., I understand if we had an option of extending > support for some version post-factum, e.g., somewhere in 2015 we'd say > "5.4 is so damn good and 5.5 has so many substantial changes that now > we want 5.4 support to be extended another couple of years, and we > feel we have people that are willing to do it". We could then talk on > it and decide it, nothing prevents it. But as I understand LTS model > means we'd have to decide it now, in 2011, and I don't see how it > works. Could some of the proponents on this model explain it? Theoretical benefits of LTS: 1. You have a version that is supported for an extended period of time. Possibly useful for Ubuntu LTS releases and RHEL and other distros that have a >3 year lifetime. 2. Keeps disruptive changes coming in on an LTS release. The goal is that LTS is the polished result of the prior non-LTS releases. 3. Makes hosting companies feel safer offering an LTS release as it means less disruption for their users. 4. Businesses like it because it's less work for them to upgrade every 3-5 years instead of every 6-18 months. Those are the ones I can think of. Although I appreciate the model with my OS, I don't think it would work well on the application/component level. Cheers, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Object and Array Literals
> a) JSON is actually being mentioned to advocate for the syntax with for the
> sake of *familiarity*.
> b) Interoperability is being confused with familiarity.
My goal is interoperability. Familiarity is a factor, definitely.
> c) Actual interoperability of the syntax with JSON is just a happy
> coincidence (same as with Ruby)
I disagree; see below.
> d) In no context this notation could function as JSON and PHP at the same
> time, mainly because PHP requires tags
I don't think they could be interchangeable, programmatically, as files, but
copying and pasting from PHP to curl for ElasticSearch would have saved me
hours of back-and-forth over the past months.
> e) There is a strong resistance to change, I bet the detractors of this
> short syntax (even with the ":") would change their opinion after using it,
> just the way some of us used to hate the idea of namespaces with "\" and
> after using it changed our opinion (specially with the autoloading standard
> that actually reflects file structure, e.g. in Symfony2).
Absolutely agree. In addition, for me to see the value in this, it took more
than just knowing how it worked, but immersing myself in this syntax (really
wanting it).
When short array syntax was first proposed, I didn't care. As I've said here a
couple times, this is not about saving 5 characters by changing "array(" into
"[", but about many other things.
> f) If JSON ceased to exist in this very moment, supporters of the syntax
> would be still supporting it and perhaps detractors would accept it.
>
> The effect of mentioning JSON, and implying direct compatibility with JSON
> technologies and JSON itself is just adding FUD.
I don't want blanket compatibility. I do want to be able to write PHP that
*CAN* be passed off to third-parties verbatim, if care is taken to do so. Most
of the time I use JSON, this care is not required, though. I don't think it's
FUD, but I do see your point in that the term "JSON" is strangely offensive to
some, and I would be willing to remove it (but not if only you two think this
way).
> +1 to removing references to JSON from the RFC, because "[ ]", "{ }" and ":"
> make enough sense by themselves.
S
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Object and Array Literals
re "JSON"
> · will never validate as JSON
>
> ·recognizablyviolates JSON quoting rules
> · recognizably violates the JSON security concept…
…
> -- I do not feel that the acronym JSON has any clarifying nor edifying
> place in the RFC describing this syntax.
> I have actually been excited about the discussion of this feature area
> and anticipate my eventual +1 if "JSON" could be removed from the RFC.
> Even though the term doesn't affect the way the feature works, by
> upvoting the RFC one is approving of wording that may make it to the
> general public, and I think this would be bad for PHP.
I was careful in the RFC to indicate that this is *not* JSON, but if others
feel as strongly as you do about the use of this term, I think it can be
removed without hurting the idea (as you indicated).
You're right that the RFC does not declare a syntax that will always validate
as JSON, nor does it respect serialization rules, but I see it more as a
declaration syntax than a serialization format, as it is proposed. The real
goal is to improve interaction with third parties, which I think the proposed
syntax would allow.
That said, other than the \u syntax, I believe that the proposed declaration
syntax would still allow JSON from a third party to me interpreted by PHP, in a
way that makes sense in PHP.
> Somewhat on a side note, I do not understand the statement that
>
>"using a strict syntax would not conform with the PHP way"
>
> or at least how it relates to this RFC.
This is directly related to the JSON-non-strictness that everyone seems to want
(me included). For example the following is completely invalid in JSON, but
normally OK (for small values of OK) in PHP:
(not-)JSON: {foo: 1}
(not-)JSON: {'foo': 1}
PHP: array(foo => 1)
PHP: array('foo' => 1)
(For anyone who doesn't follow, correct way in JSON is to use " not '.)
Thanks for the comments.
S
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PATCH] Notice on array to string convertion
On 2011-06-02, Patrick ALLAERT wrote: > I would like to introduce an E_NOTICE when an array is silently > converted to a string. > This isn't very useful as it constantly produces the following string: > "Array" and in most of the case, this is a sign of an error. > > Let me know about your feelings. +1 (for E_NOTICE) This allows warning folks easily during development of potential issues, and for those of us using tools like PHPUnit, we'll catch the problem early. At the same time, it doesn't break existing code. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
Pierre Joye wrote: If you can convince the IT departments of some of the archaic council sites > I am having to deal with that they do not have to stress test every part of > a new system ... It's exactly the same argument FROM them as you are giving > below as to why we should NOT provide support! > Fortunately the problem is being eased by the replacement of the legacy > windows systems with Linux servers but that is still slow going in some > customer sites. There is zero difference, windows or linux does not matter at the language level. If they don't want to migrate to 5.3, win or linux does not matter. Anyway, that's off topic:) What makes you say that - has PHP5.3 suddenly started working with production releases of Apache on windows? Some site will not use third party builds which is the WHOLE problem of PHP5.3 on windows ... only PHP5.2 is available to run with a stock install of Apache. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: BC-BREAK at 5.2.7
I didn't get any feedback on this. Does that mean I am on the wrong list or that no one cares?;) NB: It its not a documentation issue! Patch for Bug #49238 changed the behaviour. Am 27.05.2011 11:25, schrieb Lars Schultz: Hi internals, Jani told me to ask the list about this. I tried commenting on the bug but I guess since it's closed, no one cares about it anymore. http://bugs.php.net/bug.php?id=49189 This Change prevents us to move to anything beyond this bugfix with our codebase and I don't believe that we're the only one having this problem, as comments on Bug #49238 are suggesting. http://bugs.php.net/bug.php?id=49238 Could you please tell me wether there is any chance that this will be changeable PER_DIR again in the future of PHP or not? cheers. Lars -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
