Re: [PHP-DEV] Type hinting/casting request for vote
-1 for 5.3 0 for 5.x (if there ever will be one) +1 for 6.0 On 7.7.2009 2:52 Uhr, Ilia Alshanetsky wrote: > Last week or so there was a fairly detailed discussion on the internals > list regarding type hinting based on my original patch. Since then the > patch has been revised to address the major concerns that were > identified (breakage of binary compatibility) as well extended with > additional functionality (object hint, type casting, reflection support, > etc...). > > The final patch is available here: http://ilia.ws/patch/type_hint_53_v2.txt > The test suit is available here: http://ia.gd/patch/type_hint_tests.tar.bz2 > > I would like to ask all developers to voice their opinions of whether it > makes sense to add this to 5.3 or to throw it away (either one is fine > btw). To keep the process simple & flamewar free, please restrict > yourself to +/- (1/0), next week monday I'll run a tally of the votes > and based on the result we can determine how to proceed further. > > Ilia > -- Liip AG // Feldstrasse 133 // CH-8004 Zurich Tel +41 43 500 39 81 // Mobile +41 76 561 88 60 www.liip.ch // blog.liip.ch // GnuPG 0x5CE1DECB -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
On 7-Jul-09, at 8:43 PM, Rasmus Lerdorf wrote: That doesn't really change the timing, especially since you said you have been using it for 2 years. Why pick the week after the 5.3 release to propose it for 5.3? It makes very little sense to me, and I think consensus is building that we aren't going to add this to 5.3. I wish I had time to post the patch sooner, but timing was such that it was not an option. Plus people have tried to post the same functionality before there was patch from Hannes back in 2006, a full RFC by Fellipe in 2008 (with patch) and now my attempt in 2009. After some discussions at the developer meeting in Chicago and seeing that there was a substantial interest in the feature I've cleaned up the code and posted the patch. I think half the people who voted +1 didn't realize you were seriously thinking of pushing it into 5.3 Well, its only Tuesday there is plenty of time for people to change their mind (like some already have). Agreeably its a major decisions and I think everyone would agree it should not hinge on 1-2 votes either way, there has to be a substantial "let it in" consensus for it to go in. Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PECL-DEV] RFC readying for Pyrus 2.0.0a1 release: changes for pecl developers/consumers
Pierre Joye wrote: > On Wed, Jul 8, 2009 at 1:04 AM, Greg Beaver wrote: > > >> P.S. pecl for windows support is not in pyrus yet, since pecl4win is >> completely defunct and there's no alternative. >> > > You mean no support in general for binary package right? > The support has not been coded or ported over from the PEAR Installer, that's correct. It's just a question of getting a server set up somewhere with all the pecl extension releases built for different php versions, and then it's a piece of cake for Pyrus to download the right extension, but until that happens, there isn't much point in writing code that guesses how it will happen. Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
On Tue, Jul 7, 2009 at 08:52, Ilia Alshanetsky wrote: > Last week or so there was a fairly detailed discussion on the internals list > regarding type hinting based on my original patch. Since then the patch has > been revised to address the major concerns that were identified (breakage of > binary compatibility) as well extended with additional functionality (object > hint, type casting, reflection support, etc...). > > The final patch is available here: http://ilia.ws/patch/type_hint_53_v2.txt > The test suit is available here: http://ia.gd/patch/type_hint_tests.tar.bz2 > > I would like to ask all developers to voice their opinions of whether it > makes sense to add this to 5.3 or to throw it away (either one is fine btw). > To keep the process simple & flamewar free, please restrict yourself to +/- > (1/0), next week monday I'll run a tally of the votes and based on the > result we can determine how to proceed further. > > Ilia > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > +1 -- Regards, Wang Yi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Socket Timeout Documentation
This option sets the default value for the timeout, as though you manually called stream_set_timeout on the stream. The behavior is equivalent to using select() to wait for up to the timeout duration prior to a read or write operation. PHP does not implement "idle" timeouts; that's an application level behavior. It should be noted that a timeout in this sense can be a transient condition in the case of a read operation, it does not necessarily indicate that the connection is bad, just that no new data is available within the time allotted. More general streams bits here that may or may not be apparent from the docs: http://www.slideshare.net/wezfurlong/php-streams-lucky-dip --Wez. On Tue, Jul 7, 2009 at 5:48 AM, Hannes Magnusson wrote: > On Thu, Jul 2, 2009 at 01:01, Brian A. > Seklecki wrote: >> All: >> >> Perhaps we should clarify the socket tuneables such as: >> >> ; Default timeout for socket based streams (seconds) >> default_socket_timeout = 60 >> >> These are slightly ambiguous. e.g., we should clarify connect() >> timeouts v.s. "idle" timeouts. > > Anyone that knows the answer to this? > > >> There are at least a dozen tickets open related to timeout behavior and >> a lot of the confusion results of ambiguity in the variable naming >> convention and documentation. > > Could you post the ones you know of here please? > > -Hannes > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
-1 for 5.x +1 for 6.0 Otherwise the Perl 6 guys will starting making their own jokes about being released before PHP 6. --Wez. On Mon, Jul 6, 2009 at 8:52 PM, Ilia Alshanetsky wrote: > I would like to ask all developers to voice their opinions of whether it > makes sense to add this to 5.3 or to throw it away (either one is fine btw). > To keep the process simple & flamewar free, please restrict yourself to +/- > (1/0), next week monday I'll run a tally of the votes and based on the > result we can determine how to proceed further. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
That doesn't really change the timing, especially since you said you have been using it for 2 years. Why pick the week after the 5.3 release to propose it for 5.3? It makes very little sense to me, and I think consensus is building that we aren't going to add this to 5.3. I think half the people who voted +1 didn't realize you were seriously thinking of pushing it into 5.3 -Rasmus Ilia Alshanetsky wrote: > Rasmus, > > Well, 5.3 has been in feature lock for quite some time, its not like its > been a week or two since we went from "features in" phase to > "stabilization" phase. > > > On 7-Jul-09, at 7:14 PM, Rasmus Lerdorf wrote: > >> Paul Biggar wrote: >>> - the RFC process has been wilfully ignored (despite multiple requests) >> >> For me it is pretty hard to take a major feature for 5.3 RFC seriously >> when it comes a week after we finally get 5.3 out the door. >> >> -Rasmus > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
-1 However, this is ONLY because I do not feel PHP 5.3 is the place to put this. However, I do have to agree with Ilia here that PHP 6 is too far away and it would be nice to have this feature long before then. I would however, be very for adding something similar to this patch in a PHP 5.4 release. I don't see why a PHP 5.4 release can't be done relativly quickly (Like 6-12 months) by just making it more of a minor internal update but something that could have large impacts on user code (syntax changes for type hints). I'd like to see a feature like this out as soon as possible so that people can start adopting it. - Graham Kelly On Tue, Jul 7, 2009 at 5:21 PM, Ilia Alshanetsky wrote: > Andrei, > > PHP represents a major change on every aspect of the language, I think you > gotta appreciate it that even if it were to be released today there would be > sometime before it can certified as production ready in terms of stability > and performance. I'd go on a limb and say that PHP6 is probably 3-4 years > away from being production material and that's assuming it gets released in > the next 8-12 months. During that time people still need to develop > applications, which are getting increasingly complex and any helpful > tool/feature would be an asset. > > > > On 7-Jul-09, at 4:52 PM, Andrei Zmievski wrote: > > Ilia Alshanetsky wrote: >> >>> PHP 6 is too far off in a practical sense (sorry Andrei) from the time >>> where I can see myself using it in production or other people benefiting >>> from this function. The (simpler) variant of provided patch is what is >>> currently being used on production, if it can go into 5.3, which I see >>> myself using soon, then there is a tangible benefit from making this a >>> public feature (reduce the amount of custom patching) and spending the time >>> to refine it for public consumption and making it PHP 6 ready. If it can >>> only be added in PHP6, then the amount of interest I personally have towards >>> further evolution of this feature is very minimal. >>> So for me personally, the practically of the feature's deployment is >>> critical. >>> >> >> Ilia, I understand what you're saying, but with this kind of attitude PHP >> 6 might never arrive if we all keep putting only the things that are >> practical for our (personal) usage into 5.3, 5.4, etc. The best way to >> shorten the time horizon of 6 is to treat it as the primary target of the >> development effort. >> >> -Andrei >> > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] Type hinting/casting request for vote
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/07/2009 02:52 AM, Ilia Alshanetsky wrote: > Last week or so there was a fairly detailed discussion on the internals > list regarding type hinting based on my original patch. Since then the > patch has been revised to address the major concerns that were > identified (breakage of binary compatibility) as well extended with > additional functionality (object hint, type casting, reflection support, > etc...). > > The final patch is available here: http://ilia.ws/patch/type_hint_53_v2.txt > The test suit is available here: http://ia.gd/patch/type_hint_tests.tar.bz2 > > I would like to ask all developers to voice their opinions of whether it > makes sense to add this to 5.3 or to throw it away (either one is fine > btw). To keep the process simple & flamewar free, please restrict > yourself to +/- (1/0), next week monday I'll run a tally of the votes > and based on the result we can determine how to proceed further. +1 (5.4/6.0 and "object") - -- Tobias Schlitt tob...@schlitt.info GPG Key: 0xC462BC14 a passion for php http://schlitt.info/opensource Member of the eZ Components project http://components.ez.no -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpT6CEACgkQ5bO3TcRivBSHDACgu9ymI+3eDhyZozd+cn9f+cBi GIcAoLRK13NOZaSlQuKyMxl9Zu8TW16r =CCc0 -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
Andrei, PHP represents a major change on every aspect of the language, I think you gotta appreciate it that even if it were to be released today there would be sometime before it can certified as production ready in terms of stability and performance. I'd go on a limb and say that PHP6 is probably 3-4 years away from being production material and that's assuming it gets released in the next 8-12 months. During that time people still need to develop applications, which are getting increasingly complex and any helpful tool/feature would be an asset. On 7-Jul-09, at 4:52 PM, Andrei Zmievski wrote: Ilia Alshanetsky wrote: PHP 6 is too far off in a practical sense (sorry Andrei) from the time where I can see myself using it in production or other people benefiting from this function. The (simpler) variant of provided patch is what is currently being used on production, if it can go into 5.3, which I see myself using soon, then there is a tangible benefit from making this a public feature (reduce the amount of custom patching) and spending the time to refine it for public consumption and making it PHP 6 ready. If it can only be added in PHP6, then the amount of interest I personally have towards further evolution of this feature is very minimal. So for me personally, the practically of the feature's deployment is critical. Ilia, I understand what you're saying, but with this kind of attitude PHP 6 might never arrive if we all keep putting only the things that are practical for our (personal) usage into 5.3, 5.4, etc. The best way to shorten the time horizon of 6 is to treat it as the primary target of the development effort. -Andrei -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
Rasmus, Well, 5.3 has been in feature lock for quite some time, its not like its been a week or two since we went from "features in" phase to "stabilization" phase. On 7-Jul-09, at 7:14 PM, Rasmus Lerdorf wrote: Paul Biggar wrote: - the RFC process has been wilfully ignored (despite multiple requests) For me it is pretty hard to take a major feature for 5.3 RFC seriously when it comes a week after we finally get 5.3 out the door. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
All of the identified issues can be resolved and none of them
represent a major challenge to address. However, if there is no
consensus to put this in the near future (which at this point is 5.3),
I have hard time justifying spending further time on this. The
original patch that was posted, that did break BC was far simpler and
featureless, the changes since (which took a fair amount of work) were
specifically made to address some of the main concerns that were on
the list. I feel what is on the table right now is pretty close to
what a final product could be, to have a vote on it. If decision is
made to proceed within a practical release schedule, then suffice to
say that I'd be more then happy to put further time to address the
minor issues indicated.
On 7-Jul-09, at 7:07 PM, Paul Biggar wrote:
2009/7/7 Johannes Schlüter :
On Mon, 2009-07-06 at 20:52 -0400, Ilia Alshanetsky wrote:
Last week or so there was a fairly detailed discussion on the
internals list regarding type hinting based on my original patch.
Having an "old" 5.3 extension with a typehint expecting an array
arg_info.array_type_hint will be set to 1.
The newly compiled engine with this patch will then do
+ /* existing type already matches the hint or forced
type */
+ if (Z_TYPE_P(arg) == cur_arg_info->array_type_hint
|| Z_TYPE_P(arg) == (cur_arg_info->array_type_hint ^ (1<<7))) {
as it's main type check, but Z_TYPE_P(arg) will be IS_ARRAY (5) which
doesn't match the 1 provided by the old extension, other checks in
there
will fail too, so the valid param will be rejected whereas an integer
(IS_LONG 1) will be accepted where the extension expects an array.
I raised this in my review, to which Ilia replied "It should be fine"
(http://news.php.net/php.internals/44707). I would not have thought it
would be fine.
I had been thinking that Ilia would have to hack it to make 1 mean
array in this case, which would be ugly, but workable. Based on the
arguments in this thread, I believe it shouldn't go into 5.3 at all.
Are we allowed break the ABI for 5.4 (I would think so, but amn't
sure).
Overall, I'm very disappointed with the way this has been conducted.
When reviews were posted they are not replied to (Stas posted
http://news.php.net/php.internals/44710, I posted
http://news.php.net/php.internals/44706, and I dont see any replies
except a cursory response to mine). Furthermore:
- the RFC process has been wilfully ignored (despite multiple
requests)
- a vote was asked for when Lukas was still trying to discuss his
proposal
- the vote was take it or leave it
- there has been a general attitude of "throwing the toys out of
the pram"
I am mostly for the patch, and I 100% support the idea. However, I
feel I have to vote against it, and urge others to do the same, until
the entire mess is rectified.
Ilia, I respect the work you have put into this, but I would ask you
to withdraw the patch and the vote until these things have been sorted
out.
-1
Thanks,
Paul
--
Paul Biggar
paul.big...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PECL-DEV] RFC readying for Pyrus 2.0.0a1 release: changes for pecl developers/consumers
On Wed, Jul 8, 2009 at 1:04 AM, Greg Beaver wrote: > P.S. pecl for windows support is not in pyrus yet, since pecl4win is > completely defunct and there's no alternative. You mean no support in general for binary package right? Cheers, -- Pierre 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] Type hinting/casting request for vote
Paul Biggar wrote: > - the RFC process has been wilfully ignored (despite multiple requests) For me it is pretty hard to take a major feature for 5.3 RFC seriously when it comes a week after we finally get 5.3 out the door. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
2009/7/7 Johannes Schlüter :
> On Mon, 2009-07-06 at 20:52 -0400, Ilia Alshanetsky wrote:
>> Last week or so there was a fairly detailed discussion on the
>> internals list regarding type hinting based on my original patch.
> Having an "old" 5.3 extension with a typehint expecting an array
> arg_info.array_type_hint will be set to 1.
> The newly compiled engine with this patch will then do
>
> + /* existing type already matches the hint or forced type */
> + if (Z_TYPE_P(arg) == cur_arg_info->array_type_hint ||
> Z_TYPE_P(arg) == (cur_arg_info->array_type_hint ^ (1<<7))) {
>
> as it's main type check, but Z_TYPE_P(arg) will be IS_ARRAY (5) which
> doesn't match the 1 provided by the old extension, other checks in there
> will fail too, so the valid param will be rejected whereas an integer
> (IS_LONG 1) will be accepted where the extension expects an array.
I raised this in my review, to which Ilia replied "It should be fine"
(http://news.php.net/php.internals/44707). I would not have thought it
would be fine.
I had been thinking that Ilia would have to hack it to make 1 mean
array in this case, which would be ugly, but workable. Based on the
arguments in this thread, I believe it shouldn't go into 5.3 at all.
Are we allowed break the ABI for 5.4 (I would think so, but amn't
sure).
Overall, I'm very disappointed with the way this has been conducted.
When reviews were posted they are not replied to (Stas posted
http://news.php.net/php.internals/44710, I posted
http://news.php.net/php.internals/44706, and I dont see any replies
except a cursory response to mine). Furthermore:
- the RFC process has been wilfully ignored (despite multiple requests)
- a vote was asked for when Lukas was still trying to discuss his proposal
- the vote was take it or leave it
- there has been a general attitude of "throwing the toys out of the pram"
I am mostly for the patch, and I 100% support the idea. However, I
feel I have to vote against it, and urge others to do the same, until
the entire mess is rectified.
Ilia, I respect the work you have put into this, but I would ask you
to withdraw the patch and the vote until these things have been sorted
out.
-1
Thanks,
Paul
--
Paul Biggar
paul.big...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RFC readying for Pyrus 2.0.0a1 release: changes for pecl developers/consumers
Hi, Pyrus is within inches of its first alpha release, and as such I want to run the new features that affect PECL developers and consumers by those folks who are affected by them. Pyrus requires PHP 5.3.0 or newer, and is a dramatic leap forward from the PEAR Installer. Relevant docs to PECL are in 2 places: http://pear.php.net/manual/en/pyrus.differences.frompear.php#pyrus.differences.frompear.pecl http://pear.php.net/manual/en/pyrus.developers.pecl.php Would you take a look and comment? You can also try the current Pyrus by downloading it from the homepage of pear2.php.net: http://pear2.php.net Unlike PEAR, installation involves the ability to type "php pyrus.phar" No other monkey business needed. Thanks, Greg P.S. pecl for windows support is not in pyrus yet, since pecl4win is completely defunct and there's no alternative. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
On Mon, 2009-07-06 at 20:52 -0400, Ilia Alshanetsky wrote:
> Last week or so there was a fairly detailed discussion on the
> internals list regarding type hinting based on my original patch.
> Since then the patch has been revised to address the major concerns
> that were identified (breakage of binary compatibility) as well
> extended with additional functionality (object hint, type casting,
> reflection support, etc...).
>
> The final patch is available here: http://ilia.ws/patch/type_hint_53_v2.txt
> The test suit is available here: http://ia.gd/patch/type_hint_tests.tar.bz2
If I read the patch correctly it still breaks binary compatibility:
-#define ZEND_ARG_OBJ_INFO(pass_by_ref, name, classname, allow_null) { #name,
sizeof(#name)-1, #classname, sizeof(#classname)-1, 0, allow_null, pass_by_ref,
0, 0 },
-#define ZEND_ARG_ARRAY_INFO(pass_by_ref, name, allow_null) { #name,
sizeof(#name)-1, NULL, 0, 1, allow_null, pass_by_ref, 0, 0 },
+#define ZEND_ARG_OBJ_INFO(pass_by_ref, name, classname, allow_null) { #name,
sizeof(#name)-1, #classname, sizeof(#classname)-1, IS_CLASS, allow_null,
pass_by_ref, 0, 0 },
+#define ZEND_ARG_ARRAY_INFO(pass_by_ref, name, allow_null) { #name,
sizeof(#name)-1, NULL, 0, IS_ARRAY, allow_null, pass_by_ref, 0, 0 },
Having an "old" 5.3 extension with a typehint expecting an array
arg_info.array_type_hint will be set to 1.
The newly compiled engine with this patch will then do
+ /* existing type already matches the hint or forced type */
+ if (Z_TYPE_P(arg) == cur_arg_info->array_type_hint ||
Z_TYPE_P(arg) == (cur_arg_info->array_type_hint ^ (1<<7))) {
as it's main type check, but Z_TYPE_P(arg) will be IS_ARRAY (5) which
doesn't match the 1 provided by the old extension, other checks in there
will fail too, so the valid param will be rejected whereas an integer
(IS_LONG 1) will be accepted where the extension expects an array.
The only clean why I see for doing this is by breaking the binary
compatibility, then one could also rename "array_type_hint" and change
it's type from zend_bool to a better suited type.
Independently from this compatibility issue I'd vote -1 for 5.3.
Yes 5.3 took lng and we should, in my opinion, try to be faster with
the next "feature release" instead of changing syntax and adding other
big features in _bugfix_ releases.
I know it is bad to wait long till new features become available (btw.
that's one of the reasons why 5.3 took so long - "let's add this feature
else we have to wait so long till we get the next major version") but
adding features and changing syntax is a pain for users and at least one
of the reasons why distributors won't update the PHP versions they are
offering (What's the current PHP version in RedHat, again? - Yes, I know
people should built PHP themselves but still...)
A thing I wish for sometime is a change to our release model but never
sat really down to do the research and write a good proposal. The basic
concept would be to have a pre announced release date (maybe +/- a few
days) and therefore a "last integration date" a few weeks/months
beforehand. Ideally the release and integration date for the next
version would be set before the integration date for the current tree is
reached. After the integration day only be bug fixes should be allowed,
no new features at all. By such a model people can plan and if a feature
doesn't make it into a release it's not rejected for an unforeseeable
future. Similar models, in different flavors, are used by at least
PostgreSQL, Ubuntu, OpenSolaris and quite a few more ... but well,
that's off-topic for this thread and I wanted to do some more research
with other projects before proposing such a thing
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
+1 for HEAD and 5.3 On Tue, Jul 7, 2009 at 1:55 PM, Gwynne Raskind wrote: > On Jul 7, 2009, at 1:17 PM, Andrei Zmievski wrote: I would like to ask all developers to voice their opinions of whether it makes sense to add this to 5.3 or to throw it away (either one is fine btw). To keep the process simple & flamewar free, please restrict yourself to +/- (1/0), next week monday I'll run a tally of the votes and based on the result we can determine how to proceed further. >>> >>> +1. >> >> Sorry, I should have read better. My +1 was for the feature in general, >> not for 5.3. I think we should concentrate most of the new feature >> development on 6.0, now that 5.3 is out to avoid having yet another >> "feature-filled" 5.x release. >> >> So, once again, completely against this going into 5.3. > > > Same here. +1 for HEAD, -1 for 5.3. > > -- Gwynne > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
On Jul 7, 2009, at 1:17 PM, Andrei Zmievski wrote: I would like to ask all developers to voice their opinions of whether it makes sense to add this to 5.3 or to throw it away (either one is fine btw). To keep the process simple & flamewar free, please restrict yourself to +/- (1/0), next week monday I'll run a tally of the votes and based on the result we can determine how to proceed further. +1. Sorry, I should have read better. My +1 was for the feature in general, not for 5.3. I think we should concentrate most of the new feature development on 6.0, now that 5.3 is out to avoid having yet another "feature-filled" 5.x release. So, once again, completely against this going into 5.3. Same here. +1 for HEAD, -1 for 5.3. -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Type hinting/casting request for vote
-1 for 5.3.x . We should not add major language features at that stage. On 2009-07-07, Ilia Alshanetsky wrote: > Last week or so there was a fairly detailed discussion on the > internals list regarding type hinting based on my original patch. > Since then the patch has been revised to address the major concerns > that were identified (breakage of binary compatibility) as well > extended with additional functionality (object hint, type casting, > reflection support, etc...). > > The final patch is available here: http://ilia.ws/patch/type_hint_53_v2.txt > The test suit is available here: http://ia.gd/patch/type_hint_tests.tar.bz2 > > I would like to ask all developers to voice their opinions of whether > it makes sense to add this to 5.3 or to throw it away (either one is > fine btw). To keep the process simple & flamewar free, please restrict > yourself to +/- (1/0), next week monday I'll run a tally of the votes > and based on the result we can determine how to proceed further. > > Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
Ilia Alshanetsky wrote: PHP 6 is too far off in a practical sense (sorry Andrei) from the time where I can see myself using it in production or other people benefiting from this function. The (simpler) variant of provided patch is what is currently being used on production, if it can go into 5.3, which I see myself using soon, then there is a tangible benefit from making this a public feature (reduce the amount of custom patching) and spending the time to refine it for public consumption and making it PHP 6 ready. If it can only be added in PHP6, then the amount of interest I personally have towards further evolution of this feature is very minimal. So for me personally, the practically of the feature's deployment is critical. Ilia, I understand what you're saying, but with this kind of attitude PHP 6 might never arrive if we all keep putting only the things that are practical for our (personal) usage into 5.3, 5.4, etc. The best way to shorten the time horizon of 6 is to treat it as the primary target of the development effort. -Andrei -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
Paul Biggar wrote:
> On Tue, Jul 7, 2009 at 6:41 PM, Lukas Kahwe Smith wrote:
>> B) foo($bar);
>> function bar((int) $bar) {}
>>
>> What am I really saying with B)?
>> I don't care what you give me, I am going to use it as an int anyways?
>
> Exactly. Very simple. I would phrase it as "I'll accept anything and
> cast it to an int".
>
>
>> Of course I am also quite opposed to sticking this into 5.3.
>
> On which grounds? If you don't like the feature, please cast a -1
> vote. If its because of the BC problems, I believe you and Johannes
> have veto power on what goes into 5.3.x? If so, do you intend to use
> it?
On the grounds that 5.3.x is now in maintenance mode, no new features.
This is not a new way of conducting business in PHP, FYI.
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Bug #46367 - fputcsv does not add the correct newline character on Windows
The big issue I saw was that fgetcsv() used PHP_EOL for determining line endings, but fputcsv() didn't, which on Windows was causing csv files written by PHP not be able to be read back ( assuming auto_detect_line_endings is turned off ). John Mertic jmer...@gmail.com | http://jmertic.wordpress.com On Tue, Jul 7, 2009 at 3:22 PM, Brian Moon wrote: > On 7/7/09 1:27 PM, Jani Taskinen wrote: >> >> John Mertic kirjoitti: >>> >>> Hi All, >>> >>> Bringing this one back once more; let me know what everyone thinks >>> about it. If it's safe to commit than if someone could ( or give me >>> the karma to do so ) that would be great. If not, let me know what >>> should be done about it instead. >> >> Is \r\n okay on Mac? Is \r okay on Windows? etc. >> >> Short: Shouldn't this be always \r\n? Or better yet, default to \r\n and >> add extra option for fputcsv with which you can set it to anything you >> like.. :) >> >> --Jani > > The only program I know of in existence that has issues is Notepad on > Windows. All the mac programs I use will deal with whatever. > > Having said that, it should be just as flexible for creating CSV files as > fgetcsv is for reading them. > > Of course, a good ol' fputs does a fine job of making a CSV file too. > > -- > > Brian. > > http://brian.moonspot.net/ > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Type hinting/casting request for vote
+1 -- Marcelo Araujo
Re: [PHP-DEV] PHP LLVM JIT-Compiler
Hi, So there is some information about the project in the CVS repository. Let me first say that the project is not mature enough to run your favorite app. It is capable of executing some small tests, but not complex apps. You can use either clang or llvm-gcc to compile the stuff, although the last developments were done with clang only. The Install file says it was last tested with svn revision r59219 of llvm (I don't know to which llvm version it maps to), so it might have some trouble compiling with the latest svn version of llvm. There hasn't been any developments in the last 6 months because I've been pretty busy. I would be happy to discuss any development plans with you if you wish. There are always a lot of things to do :) Nuno - Original Message - Hi, I recently found the jit compiler for php (http://pecl.php.net/package/llvm). Are there any information avaible on this project? I just found that the student 'dropped out' of the project, but from then, nothing. Does anyone know which version of llvm this needs to compile (and which version of llvm-gcc?), and are there any further information on goals, todo plans etc? Maybe I could take up the work and try to improve that project, but for that i'd need some more information. I already know the talk and the slides of Nuno at llvm.org. Yours Cornelius -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Type hinting/casting request for vote
+1 2009/7/7 Ryan Panning > Ilia Alshanetsky wrote: > >> Last week or so there was a fairly detailed discussion on the internals >> list regarding type hinting based on my original patch. Since then the patch >> has been revised to address the major concerns that were identified >> (breakage of binary compatibility) as well extended with additional >> functionality (object hint, type casting, reflection support, etc...). >> >> The final patch is available here: >> http://ilia.ws/patch/type_hint_53_v2.txt >> The test suit is available here: >> http://ia.gd/patch/type_hint_tests.tar.bz2 >> >> I would like to ask all developers to voice their opinions of whether it >> makes sense to add this to 5.3 or to throw it away (either one is fine btw). >> To keep the process simple & flamewar free, please restrict yourself to +/- >> (1/0), next week monday I'll run a tally of the votes and based on the >> result we can determine how to proceed further. >> >> Ilia >> > > +1 > > As for when, I'd say it should wait for the next "major" release, 5.4 or > 6.0. But then again, I don't want to wait several years for a feature being > discussed now, so I'll go with 5.3.x. > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Jarismar C. Silva jarismar@gmail.com
Re: [PHP-DEV] [PATCH] Bug #46367 - fputcsv does not add the correct newline character on Windows
On 7/7/09 1:27 PM, Jani Taskinen wrote: John Mertic kirjoitti: Hi All, Bringing this one back once more; let me know what everyone thinks about it. If it's safe to commit than if someone could ( or give me the karma to do so ) that would be great. If not, let me know what should be done about it instead. Is \r\n okay on Mac? Is \r okay on Windows? etc. Short: Shouldn't this be always \r\n? Or better yet, default to \r\n and add extra option for fputcsv with which you can set it to anything you like.. :) --Jani The only program I know of in existence that has issues is Notepad on Windows. All the mac programs I use will deal with whatever. Having said that, it should be just as flexible for creating CSV files as fgetcsv is for reading them. Of course, a good ol' fputs does a fine job of making a CSV file too. -- Brian. http://brian.moonspot.net/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Type hinting/casting request for vote
Ilia Alshanetsky wrote: Last week or so there was a fairly detailed discussion on the internals list regarding type hinting based on my original patch. Since then the patch has been revised to address the major concerns that were identified (breakage of binary compatibility) as well extended with additional functionality (object hint, type casting, reflection support, etc...). The final patch is available here: http://ilia.ws/patch/type_hint_53_v2.txt The test suit is available here: http://ia.gd/patch/type_hint_tests.tar.bz2 I would like to ask all developers to voice their opinions of whether it makes sense to add this to 5.3 or to throw it away (either one is fine btw). To keep the process simple & flamewar free, please restrict yourself to +/- (1/0), next week monday I'll run a tally of the votes and based on the result we can determine how to proceed further. Ilia +1 As for when, I'd say it should wait for the next "major" release, 5.4 or 6.0. But then again, I don't want to wait several years for a feature being discussed now, so I'll go with 5.3.x. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
On 7-Jul-09, at 1:35 PM, Jeff Griffiths wrote: On 07/07/09 10:17 AM, Andrei Zmievski wrote: Andrei Zmievski wrote: I would like to ask all developers to voice their opinions of whether it makes sense to add this to 5.3 or to throw it away (either one is fine btw). To keep the process simple & flamewar free, please restrict yourself to +/- (1/0), next week monday I'll run a tally of the votes and based on the result we can determine how to proceed further. +1. Sorry, I should have read better. My +1 was for the feature in general, not for 5.3. I think we should concentrate most of the new feature development on 6.0, now that 5.3 is out to avoid having yet another "feature-filled" 5.x release. So, once again, completely against this going into 5.3. +1 for what Andrei said ( to further muddy the waters ). Ilia, why 5.3 or die? This feature should be in HEAD IMO. PHP 6 is too far off in a practical sense (sorry Andrei) from the time where I can see myself using it in production or other people benefiting from this function. The (simpler) variant of provided patch is what is currently being used on production, if it can go into 5.3, which I see myself using soon, then there is a tangible benefit from making this a public feature (reduce the amount of custom patching) and spending the time to refine it for public consumption and making it PHP 6 ready. If it can only be added in PHP6, then the amount of interest I personally have towards further evolution of this feature is very minimal. So for me personally, the practically of the feature's deployment is critical. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
Ilia Alshanetsky wrote: > Last week or so there was a fairly detailed discussion on the internals > list regarding type hinting based on my original patch. Since then the > patch has been revised to address the major concerns that were > identified (breakage of binary compatibility) as well extended with > additional functionality (object hint, type casting, reflection support, > etc...). > > The final patch is available here: http://ilia.ws/patch/type_hint_53_v2.txt > The test suit is available here: http://ia.gd/patch/type_hint_tests.tar.bz2 > > I would like to ask all developers to voice their opinions of whether it > makes sense to add this to 5.3 or to throw it away (either one is fine > btw). To keep the process simple & flamewar free, please restrict > yourself to +/- (1/0), next week monday I'll run a tally of the votes > and based on the result we can determine how to proceed further. -1 on 5.3. The window for adding new major features to 5.3 is obviously long gone. Not sure why you are even suggesting it. +0 on parts of it for the next major release. You still haven't convinced me that strict type checking won't cause more problems than it will solve, but I do see the benefits. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Bug #46367 - fputcsv does not add the correct newline character on Windows
John Mertic kirjoitti: Hi All, Bringing this one back once more; let me know what everyone thinks about it. If it's safe to commit than if someone could ( or give me the karma to do so ) that would be great. If not, let me know what should be done about it instead. Is \r\n okay on Mac? Is \r okay on Windows? etc. Short: Shouldn't this be always \r\n? Or better yet, default to \r\n and add extra option for fputcsv with which you can set it to anything you like.. :) --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
On 07.07.2009, at 20:04, Paul Biggar wrote: Of course I am also quite opposed to sticking this into 5.3. On which grounds? If you don't like the feature, please cast a -1 That adding language syntax sugar anything but a major or minor release is a bad idea. And this even if Ilia does manage to solve the BC issues. If there are BC issues, we shouldnt even have to talk about 5.3 for one second. vote. If its because of the BC problems, I believe you and Johannes have veto power on what goes into 5.3.x? If so, do you intend to use it? I dont think we have a veto power, nor would I want to use it if we did have one. One job is to keep things focused and appeal to the general sanity if we feel that things are going off track. I would want to appeal to the general sanity on this one though :) regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
On Tue, Jul 7, 2009 at 6:41 PM, Lukas Kahwe Smith wrote:
> B) foo($bar);
> function bar((int) $bar) {}
>
> What am I really saying with B)?
> I don't care what you give me, I am going to use it as an int anyways?
Exactly. Very simple. I would phrase it as "I'll accept anything and
cast it to an int".
> Of course I am also quite opposed to sticking this into 5.3.
On which grounds? If you don't like the feature, please cast a -1
vote. If its because of the BC problems, I believe you and Johannes
have veto power on what goes into 5.3.x? If so, do you intend to use
it?
> Finally I would like to ask to rename this entire feature (including what we
> currently already have) to "type checking" or something other than "hint" in
> the documentation.
Seconded.
Thanks,
Paul
--
Paul Biggar
paul.big...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] bug tracker planning
The bug system today works fine but improvements are being made. I've gone through the lists and details from past attempts and will list ideas here. Please do not vote, but if a particular item appears like a bad idea then please explain. Or, discuss additional (or modified) ideas that will be useful to the PHP project. The new system[1] is based off the pear.php.net bug system (via Jani), which long ago was a fork of our current (bugs.php.net). Because of this, some of these items are already available via the pear geeks. The plan is to have one bug tracker that includes PEAR+PECL+Core+GTK +Etc. It's also planning to go live after Stage #1 is completed, and also Jani and 2009 GSoC student Felipe Ribeiro are working on this project. Soonish a test system will be setup for all to break. Yes, this really is happening. Most people like the current system because it's simple, and I don't foresee this changing. First stage: - Cleanup code (in progress) - Attachments : For a diff, test, backtrace, screenshot, whatever. (done) - Package/Type separation : Packages (like extensions) and Bug Types (like feature requests) are separate (done) - Defined/Documented permissions : For example, so we all know if a random person can comment on a bogus bug - Preview button, instead of only submit (almost done) - Deal with bug id clashes from current PECL/PEAR/PHP bug trackers, and associated links - Importing - Testing Second stage: - Additional history : When a bug was opened/closed etc. Currently we don't log this except in emails - Reclassification : Discuss how we handle this, like should old/new lists both receive emails? - Consider different captcha (like reCaptcha) for anonymous users - Voting : Do we use or care about this? Improve? - nofeedback improvements : People assume this means closed, when it does not Third stage: - Subscriptions : Allow people to subscribe to RSS and/or receive emails per bug/package - Tagging : Allow people to optionally attach tags to bugs - IRC integration : Allow bot integration to an IRC channel, like a #php.bugs resurrection - Optional milestones (in pearweb today) - Integrate with VCS. Research this, KISS. Ex. A commit containing "PHP Bug #42" automagically appends info to the bugs db - Befriend systems like http://bts-link.alioth.debian.org/ - OpenID support, see also http://wiki.php.net/ideas/phpnetauth - Username finder for the 'assigned' boxes, see also http://people.php.net/ And as always, additional volunteers are welcome. Regards, Philip [1] http://cvs.php.net/viewvc.cgi/pear/Bugtracker/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] Bug #46367 - fputcsv does not add the correct newline character on Windows
Hi All, Bringing this one back once more; let me know what everyone thinks about it. If it's safe to commit than if someone could ( or give me the karma to do so ) that would be great. If not, let me know what should be done about it instead. Thanks! John Mertic jmer...@gmail.com | http://jmertic.wordpress.com file.c.patch Description: application/force-download -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
Hi,
I am -1 on the inclusion of cast support. IMHO this part isnt thought
out and was just thrown in to silence those who feel that there is a
use case for non strict type hinting. But in that case I might as well
leave the type cast in the API calling code. The number of characters
saved are next to nothing, the performance impact is probably also
fairly irrelevant and with this syntax I get slapped and then I can
choose if I want to cast manually or do something else. But just
hiding things by just blindly casting seems counter productive (which
is why I proposed to add reasonable checks before doing the cast in my
RFC that would make things more compatible with data coming out of a
database, config file or other trusted data source). I just do not see
what is gained at all from:
A) foo((int)$bar);
function bar(int $bar) {}
vs.
B) foo($bar);
function bar((int) $bar) {}
What am I really saying with B)?
I don't care what you give me, I am going to use it as an int anyways?
IMHO no need to introduce a special syntax for this.
Of course I am also quite opposed to sticking this into 5.3.
Finally I would like to ask to rename this entire feature (including
what we currently already have) to "type checking" or something other
than "hint" in the documentation.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
On 07/07/09 10:17 AM, Andrei Zmievski wrote: Andrei Zmievski wrote: I would like to ask all developers to voice their opinions of whether it makes sense to add this to 5.3 or to throw it away (either one is fine btw). To keep the process simple & flamewar free, please restrict yourself to +/- (1/0), next week monday I'll run a tally of the votes and based on the result we can determine how to proceed further. +1. Sorry, I should have read better. My +1 was for the feature in general, not for 5.3. I think we should concentrate most of the new feature development on 6.0, now that 5.3 is out to avoid having yet another "feature-filled" 5.x release. So, once again, completely against this going into 5.3. +1 for what Andrei said ( to further muddy the waters ). Ilia, why 5.3 or die? This feature should be in HEAD IMO. Aside: I'm personally really excited at the possibilities of improving completion in Komodo for code that uses this feature. Jeff -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
Andrei Zmievski wrote: I would like to ask all developers to voice their opinions of whether it makes sense to add this to 5.3 or to throw it away (either one is fine btw). To keep the process simple & flamewar free, please restrict yourself to +/- (1/0), next week monday I'll run a tally of the votes and based on the result we can determine how to proceed further. +1. Sorry, I should have read better. My +1 was for the feature in general, not for 5.3. I think we should concentrate most of the new feature development on 6.0, now that 5.3 is out to avoid having yet another "feature-filled" 5.x release. So, once again, completely against this going into 5.3. -Andrei -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
Ilia Alshanetsky wrote: Last week or so there was a fairly detailed discussion on the internals list regarding type hinting based on my original patch. Since then the patch has been revised to address the major concerns that were identified (breakage of binary compatibility) as well extended with additional functionality (object hint, type casting, reflection support, etc...). The final patch is available here: http://ilia.ws/patch/type_hint_53_v2.txt The test suit is available here: http://ia.gd/patch/type_hint_tests.tar.bz2 I would like to ask all developers to voice their opinions of whether it makes sense to add this to 5.3 or to throw it away (either one is fine btw). To keep the process simple & flamewar free, please restrict yourself to +/- (1/0), next week monday I'll run a tally of the votes and based on the result we can determine how to proceed further. +1. -a -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: srinatar
I would like to take care of http://bugs.php.net/bug.php?id=48695. I guess, David Soria Parra(dsp) and Pierre Joye has said ok to my request. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Soap over SSL and
On 07/07/09 10:18, Brian A. Seklecki wrote: If it did use libcurl, dozens of problems over the last few years would have magically solved themselves (pipe-line'ing, keep-alive, socket options, PKI, etc.) Not only this extension but pretty much everything should use curl IMHO, it is included in all *nixes and works on windows too.. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Type hinting/casting request for vote
On Tue, Jul 7, 2009 at 3:53 PM, Greg Beaver wrote:
> 2) have 1 syntax, T_*_CAST as in function ((int) $a) {} and have that
> mean strict type hinting.
I dont think this is a good option. Having features dictated by trying
to keep the lexer/parser clean is a bad idea. If the lexer cannot be
fixed, I think the better option is to ruin things for people calling
things Bool, rather than compromising the feature. (I am assuming that
people are still able to call things \mynamespace\bool -- if not, that
changes things).
Thanks,
Paul
--
Paul Biggar
paul.big...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Type hinting/casting request for vote
Greg,
the T_CLASS fix you've suggested in your e-mail to me could work, but
calling a type hint "class" rather then "object" seems a little
awkward to me. Plus to your point and earlier Stas' e-mail the patch
would reserve the a whole bunch of type based keywords, personally I
feel that this is fine, because its seems wrong to call classes by
type names, but recognize a fair number of people maybe doing it.
I'll take a look at the lexer, but I am not sure there is a simple
solution around that.
On 7-Jul-09, at 10:53 AM, Greg Beaver wrote:
Christian Schneider wrote:
Stan Vassilev wrote:
+1 if the object type hint is change to use T_CLASS so we don't
break
every external package using "Object" as a base class.
http://www.google.com/codesearch?as_q=class\s%2Bobject&btnG=Search
+
Code
&hl
=
en
&as_lang
=
php
&as_license_restrict
=i&as_license=&as_package=&as_filename=&as_case=
Or this can wait until 6.0, when (as I hear) we'll have case-
sensitive
class names, so Object/object, Int/int won't cause collisions.
This won't help much because of functions:
This changes my vote to -1 in any version without a technical fix in
the
patch to avoid this problem.
There are 2 ways to avoid this problem
1) create a patch allowing reserved words as function/class names.
I've
already tried this for a previous reason, and it's difficult to do
without vastly over-complicating the lexer.
2) have 1 syntax, T_*_CAST as in function ((int) $a) {} and have that
mean strict type hinting.
Ilia: if you can include a lexer patch that allows reserved words in
key
places, I'd be willing to modify my vote. The problem is supporting
static class things requires lookahead tokens, thus one would need to
specify that this pseudo-regex is a T_STRING:
/(LABEL)(?:\s*->|::)/
not to mention having a new "looking for label" state that is entered
whenever we encounter class|interface\s+(extends|implements|{) or
T_NEW
Although having this freedom would be nice, I prefer #2, it's a whole
lot simpler.
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
that vote is for anything coming after 5.3.x (be 5.4 or 6.x), did not see the 5.3 only requirement (which makes no sense). I'm generally -1 on any major change for 5.3.x. On Tue, Jul 7, 2009 at 11:42 AM, Pierre Joye wrote: > +1 > > > > > -- > Pierre > > http://blog.thepimp.net | http://www.libgd.org > -- Pierre 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] Type hinting/casting request for vote
Sebastian Bergmann schrieb: > +1 Just to be clear, my vote was for putting this into (PHP_5_3) + 1, not into PHP 5.3.1. -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Type hinting/casting request for vote
On 07.07.2009, at 16:15, Stan Vassilev wrote: +1 if the object type hint is change to use T_CLASS so we don't break every external package using "Object" as a base class. http://www.google.com/codesearch?as_q=class\s%2Bobject&btnG=Search + Code &hl = en &as_lang = php &as_license_restrict=i&as_license=&as_package=&as_filename=&as_case= Greg Or this can wait until 6.0, when (as I hear) we'll have case- sensitive class names, so Object/object, Int/int won't cause collisions. I'm really puzzled why a non-essential, and for the past months (years?) controversial and always rejected feature such as strict type hints, has everyone turning 180 degrees and putting it in a minor release in the course of a week. amen to that. regards Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Type hinting/casting request for vote
Christian Schneider wrote:
> Stan Vassilev wrote:
>>> +1 if the object type hint is change to use T_CLASS so we don't break
>>> every external package using "Object" as a base class.
>>> http://www.google.com/codesearch?as_q=class\s%2Bobject&btnG=Search+Code&hl=en&as_lang=php&as_license_restrict=i&as_license=&as_package=&as_filename=&as_case=
>> Or this can wait until 6.0, when (as I hear) we'll have case-sensitive
>> class names, so Object/object, Int/int won't cause collisions.
>
> This won't help much because of functions:
This changes my vote to -1 in any version without a technical fix in the
patch to avoid this problem.
There are 2 ways to avoid this problem
1) create a patch allowing reserved words as function/class names. I've
already tried this for a previous reason, and it's difficult to do
without vastly over-complicating the lexer.
2) have 1 syntax, T_*_CAST as in function ((int) $a) {} and have that
mean strict type hinting.
Ilia: if you can include a lexer patch that allows reserved words in key
places, I'd be willing to modify my vote. The problem is supporting
static class things requires lookahead tokens, thus one would need to
specify that this pseudo-regex is a T_STRING:
/(LABEL)(?:\s*->|::)/
not to mention having a new "looking for label" state that is entered
whenever we encounter class|interface\s+(extends|implements|{) or T_NEW
Although having this freedom would be nice, I prefer #2, it's a whole
lot simpler.
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Type hinting/casting request for vote
On Tue, Jul 7, 2009 at 3:15 PM, Stan Vassilev wrote: > I'm really puzzled why a non-essential, and for the past months (years?) > controversial and always rejected feature such as strict type hints, has > everyone turning 180 degrees and putting it in a minor release in the course > of a week. Because nearly everyone wants it, and people think it might actually get in this time. It was never rejected, people simply couldnt agree on what it was they wanted, so it never got in. Nearly there, though... Paul -- Paul Biggar paul.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
+1 On Jul 6, 2009, at 7:52 PM, Ilia Alshanetsky wrote: Last week or so there was a fairly detailed discussion on the internals list regarding type hinting based on my original patch. Since then the patch has been revised to address the major concerns that were identified (breakage of binary compatibility) as well extended with additional functionality (object hint, type casting, reflection support, etc...). The final patch is available here: http://ilia.ws/patch/type_hint_53_v2.txt The test suit is available here: http://ia.gd/patch/type_hint_tests.tar.bz2 I would like to ask all developers to voice their opinions of whether it makes sense to add this to 5.3 or to throw it away (either one is fine btw). To keep the process simple & flamewar free, please restrict yourself to +/- (1/0), next week monday I'll run a tally of the votes and based on the result we can determine how to proceed further. Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
I would like to ask all developers to voice their opinions of whether it makes sense to add this to 5.3 or to throw it away (either one is fine btw). To keep the process simple & flamewar free, please restrict yourself to +/- (1/0), next week monday I'll run a tally of the votes and based on the result we can determine how to proceed further. I'm struggling here but must emit -1 because PHP does not add features within point (5.3.x) releases, especially those affecting syntax like this. But if this philosophy changes, then also add traits. :) Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Type hinting/casting request for vote
Stan Vassilev wrote: >> +1 if the object type hint is change to use T_CLASS so we don't break >> every external package using "Object" as a base class. >> http://www.google.com/codesearch?as_q=class\s%2Bobject&btnG=Search+Code&hl=en&as_lang=php&as_license_restrict=i&as_license=&as_package=&as_filename=&as_case= > > Or this can wait until 6.0, when (as I hear) we'll have case-sensitive > class names, so Object/object, Int/int won't cause collisions. This won't help much because of functions: http://www.google.com/codesearch?hl=en&start=10&sa=N&q=function\s%2B(bool|boolean|string|binary|unicode|int|integer|long|real|double|float|resource|numeric|scalar|object)\s*\(+lang:php Cheers, - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
-1 for 5.x +1 for 6.0 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
I would like to ask all developers to voice their opinions of whether it makes sense to add this to 5.3 or to throw it away (either one is fine btw). I don't want to start a long discussion, but IMO this and other major language changes doen't belong in a point release of 5.3.x (whether it's 5.3.2 or 5.3.192). so: -1 in 5.3 -1 throw away +1 in HEAD (or 5.4; sorry for opening $canOfWorms) S -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Type hinting/casting request for vote
Stan Vassilev wrote: >> +1 if the object type hint is change to use T_CLASS so we don't break >> every external package using "Object" as a base class. >> >> http://www.google.com/codesearch?as_q=class\s%2Bobject&btnG=Search+Code&hl=en&as_lang=php&as_license_restrict=i&as_license=&as_package=&as_filename=&as_case= >> >> >> Greg > > Or this can wait until 6.0, when (as I hear) we'll have case-sensitive > class names, so Object/object, Int/int won't cause collisions. > > I'm really puzzled why a non-essential, and for the past months > (years?) controversial and always rejected feature such as strict type > hints, has everyone turning 180 degrees and putting it in a minor > release in the course of a week. Hi, To clarify, my vote was for 6.0.0, I did not catch the "put in 5.3" part of Ilia's original email. Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Soap over SSL and
On Tue, 2009-07-07 at 15:42 +0200, endrazine wrote: > > It is lacking any type of authentication of the payment gateway, which > is not acceptable. > I agree+++. The problem is that PHP SOAP uses an internal "streams" library instead of libcurl; the former lacks, the later has, client/server PKI support. If it did use libcurl, dozens of problems over the last few years would have magically solved themselves (pipe-line'ing, keep-alive, socket options, PKI, etc.) Support needs to be added to PHP for this and it's been on the back-burner for me, but I think it is time to take it to the next level. This being 2009, and all, perhaps a few organizations can pool resources and sponsor the needed development. ~BAS > So in a nutshell, my problem is : can I get acces to the x509 > certificate used by SoapClient ? Is there an api to then verify the > whole authority certification chain up to the root certificates I may > decide to trust automagically, or shall I use the openssl api ? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
2009/7/7 Ilia Alshanetsky : > Last week or so there was a fairly detailed discussion on the internals list > regarding type hinting based on my original patch. Since then the patch has > been revised to address the major concerns that were identified (breakage of > binary compatibility) as well extended with additional functionality (object > hint, type casting, reflection support, etc...). +1 -- regrads, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Type hinting/casting request for vote
+1 if the object type hint is change to use T_CLASS so we don't break every external package using "Object" as a base class. http://www.google.com/codesearch?as_q=class\s%2Bobject&btnG=Search+Code&hl=en&as_lang=php&as_license_restrict=i&as_license=&as_package=&as_filename=&as_case= Greg Or this can wait until 6.0, when (as I hear) we'll have case-sensitive class names, so Object/object, Int/int won't cause collisions. I'm really puzzled why a non-essential, and for the past months (years?) controversial and always rejected feature such as strict type hints, has everyone turning 180 degrees and putting it in a minor release in the course of a week. Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Type hinting/casting request for vote
Ilia Alshanetsky wrote: Last week or so there was a fairly detailed discussion on the internals list regarding type hinting based on my original patch. Since then the patch has been revised to address the major concerns that were identified (breakage of binary compatibility) as well extended with additional functionality (object hint, type casting, reflection support, etc...). The final patch is available here: http://ilia.ws/patch/type_hint_53_v2.txt The test suit is available here: http://ia.gd/patch/type_hint_tests.tar.bz2 I would like to ask all developers to voice their opinions of whether it makes sense to add this to 5.3 or to throw it away (either one is fine btw). To keep the process simple & flamewar free, please restrict yourself to +/- (1/0), next week monday I'll run a tally of the votes and based on the result we can determine how to proceed further. Ilia +1 with the same caveat as Greg (please object not Object) Thanks, Elizabeth -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
Ilia Alshanetsky wrote: [..] I would like to ask all developers to voice their opinions of whether it makes sense to add this to 5.3 or to throw it away (either one is fine btw). +1 [..] - Mark -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Type hinting/casting request for vote
Greg Beaver wrote: >> I would like to ask all developers to voice their opinions of whether it >> makes sense to add this to 5.3 or to throw it away (either one is fine >> btw). To keep the process simple & flamewar free, please restrict >> yourself to +/- (1/0), next week monday I'll run a tally of the votes >> and based on the result we can determine how to proceed further. > > +1 if the object type hint is change to use T_CLASS so we don't break > every external package using "Object" as a base class. -1 because of the new keywords bool, boolean, string, binary, unicode, int, integer, long, real, double, float, resource, numeric, scalar, object which cannot be used as function or class names any more (major BC break). I have more comments but they are minor so I restrict myself to this big one... Cheers, - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
+1 from me On Tue, Jul 7, 2009 at 1:52 AM, Ilia Alshanetsky wrote: > Last week or so there was a fairly detailed discussion on the internals > list regarding type hinting based on my original patch. Since then the patch > has been revised to address the major concerns that were identified > (breakage of binary compatibility) as well extended with additional > functionality (object hint, type casting, reflection support, etc...). > > The final patch is available here: > http://ilia.ws/patch/type_hint_53_v2.txt > The test suit is available here: > http://ia.gd/patch/type_hint_tests.tar.bz2 > > I would like to ask all developers to voice their opinions of whether it > makes sense to add this to 5.3 or to throw it away (either one is fine btw). > To keep the process simple & flamewar free, please restrict yourself to +/- > (1/0), next week monday I'll run a tally of the votes and based on the > result we can determine how to proceed further. > > Ilia > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
[PHP-DEV] Re: Type hinting/casting request for vote
Ilia Alshanetsky wrote: > Last week or so there was a fairly detailed discussion on the internals > list regarding type hinting based on my original patch. Since then the > patch has been revised to address the major concerns that were > identified (breakage of binary compatibility) as well extended with > additional functionality (object hint, type casting, reflection support, > etc...). > > The final patch is available here: http://ilia.ws/patch/type_hint_53_v2.txt > The test suit is available here: http://ia.gd/patch/type_hint_tests.tar.bz2 > > I would like to ask all developers to voice their opinions of whether it > makes sense to add this to 5.3 or to throw it away (either one is fine > btw). To keep the process simple & flamewar free, please restrict > yourself to +/- (1/0), next week monday I'll run a tally of the votes > and based on the result we can determine how to proceed further. +1 if the object type hint is change to use T_CLASS so we don't break every external package using "Object" as a base class. http://www.google.com/codesearch?as_q=class\s%2Bobject&btnG=Search+Code&hl=en&as_lang=php&as_license_restrict=i&as_license=&as_package=&as_filename=&as_case= Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Soap over SSL and
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello dear list, I realise this is probably not the best place to ask this kind of questions, but after doing my howmeworks on google and php.net, I can't find a decent solution to a development problem I thought would be common. If this is strictly off topic, feel free to let me know. I am currently interfacing a client's ecommerce website (let's call it C) with an online payment gateway (let's call it G). The communication between C and G is done over ssl, using Soap. The payment gateway's support team provided us a sample php script responsible to connect to G, make the payment etc. It lacks any kind of security checks, and in particular doesn't verify G's SSL certificate, nor does it verify that the certificate actually comes from a certification authority that we do in fact trust. Internal experiments showed that if presented a fake self signed certificate using the domain name of the gateway, the web app of C doesn't realize the subterfuge and proceeds to the payment, which is indeed quite anoying from a security point of view. C is a php webapp running on php 5.2.9 under apache 2.x, here is the full httpd banner: Apache/2.2.11 (Ubuntu) PHP/5.2.9 mod_ssl/2.2.11 OpenSSL/0.9.8g Server The code provided by the gateway's support team to perform the connection to G looks like this: $client = new SoapClient( $this->WSDL_SOAP, $this->header_soap); $doWebPaymentResponse = $client->doWebPayment($doWebPaymentRequest); return util::responseToArray($doWebPaymentResponse); It is lacking any type of authentication of the payment gateway, which is not acceptable. So in a nutshell, my problem is : can I get acces to the x509 certificate used by SoapClient ? Is there an api to then verify the whole authority certification chain up to the root certificates I may decide to trust automagically, or shall I use the openssl api ? Note: I have been suggested to rely on SoapClient like above to perform the payment, while opening a second socket (possibly using libcurl, or even using the binary openssl itself) which would only verify the SSL certification chain "in parallel". This seems quite a bad solution to me since it is not verifying anything on the connection made by SoapClient : imho there will be a race condition however I implement it ;( Note2: I _did_ try to get the payment gateway's team to provide us the necessary php code, but they don't seem interrested in making things work in a secure way :( In case SoapClient couldn't be used for this purpose, what is the suggested way to extend it's capabilities (hooking/patching/writing an apache module) ? Thanks for your time, - -- Jonathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpTUMcACgkQK/YAm7PYybkkHgCfdbuhceR6BDdONspDN7CyZNEk Z4IAmgPopaVgui/Ils/FraDXNhIEkUC8 =t1Gv -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
+1 Rafael Dohms On Tue, Jul 7, 2009 at 9:44 AM, Richard Quadling wrote: > 2009/7/7 Ilia Alshanetsky : > > Last week or so there was a fairly detailed discussion on the internals > list > > regarding type hinting based on my original patch. Since then the patch > has > > been revised to address the major concerns that were identified (breakage > of > > binary compatibility) as well extended with additional functionality > (object > > hint, type casting, reflection support, etc...). > > > > The final patch is available here: > http://ilia.ws/patch/type_hint_53_v2.txt > > The test suit is available here: > http://ia.gd/patch/type_hint_tests.tar.bz2 > > > > I would like to ask all developers to voice their opinions of whether it > > makes sense to add this to 5.3 or to throw it away (either one is fine > btw). > > To keep the process simple & flamewar free, please restrict yourself to > +/- > > (1/0), next week monday I'll run a tally of the votes and based on the > > result we can determine how to proceed further. > > > > Ilia > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > +1 > > > -- > - > Richard Quadling > Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 > "Standing on the shoulders of some very clever giants!" > I need a car : http://snipurl.com/l4pih > ZOPA : http://uk.zopa.com/member/RQuadling > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] Type hinting/casting request for vote
2009/7/7 Ilia Alshanetsky : > Last week or so there was a fairly detailed discussion on the internals list > regarding type hinting based on my original patch. Since then the patch has > been revised to address the major concerns that were identified (breakage of > binary compatibility) as well extended with additional functionality (object > hint, type casting, reflection support, etc...). > > The final patch is available here: http://ilia.ws/patch/type_hint_53_v2.txt > The test suit is available here: http://ia.gd/patch/type_hint_tests.tar.bz2 > > I would like to ask all developers to voice their opinions of whether it > makes sense to add this to 5.3 or to throw it away (either one is fine btw). > To keep the process simple & flamewar free, please restrict yourself to +/- > (1/0), next week monday I'll run a tally of the votes and based on the > result we can determine how to proceed further. > > Ilia > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > +1 -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!" I need a car : http://snipurl.com/l4pih ZOPA : http://uk.zopa.com/member/RQuadling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
On 06/07/09 20:52, Ilia Alshanetsky wrote: The final patch is available here: http://ilia.ws/patch/type_hint_53_v2.txt The test suit is available here: http://ia.gd/patch/type_hint_tests.tar.bz2 +1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Official DVCS mirrors, was: Commit freeze (moving to SVN)!
On 07.07.2009 13:55, Thomas Koch wrote: > Hi, > > are there people who're interested to host semi-official > GIT-/HG-/BZR-mirrors? > Doing an initial GIT-SVN sync causes quite a lot of traffic on the subversion > server and if a douzens people set up there mirrors in the next week, this > traffic is multiplied. > If nobody else will, then I'll surely once setup my own GIT-SVN mirror of PHP. Yes, please do. Where are you going to set it up? Github? -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
+1 -- Slan, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
+1 Patrick Allaert --- http://code.google.com/p/peclapm/ - Alternative PHP Monitor -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Official DVCS mirrors, was: Commit freeze (moving to SVN)!
On 2009-07-07, Thomas Koch wrote: > Hi, > > are there people who're interested to host semi-official > GIT-/HG-/BZR-mirrors? > Doing an initial GIT-SVN sync causes quite a lot of traffic on the subversion > server and if a douzens people set up there mirrors in the next week, this > traffic is multiplied. > If nobody else will, then I'll surely once setup my own GIT-SVN mirror of PHP. bitbucket.org will setup an mercurial mirror of the php svn repository. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Official DVCS mirrors, was: Commit freeze (moving to SVN)!
Hi, are there people who're interested to host semi-official GIT-/HG-/BZR-mirrors? Doing an initial GIT-SVN sync causes quite a lot of traffic on the subversion server and if a douzens people set up there mirrors in the next week, this traffic is multiplied. If nobody else will, then I'll surely once setup my own GIT-SVN mirror of PHP. Best regards, Thomas Koch > Hi all > > The time has come that we move to SVN and the switch flipping will be > happening next Friday (July 10th, 2009)! > > There will be a total cvs.php.net lockdown as of late Thursday, with > svn.php.net replacing it ! > > The fire department (which needs more volunteers!) will be working > through the weekend to extinguish fires that will break out due to the > transition. > > A (very light) FAQ is on the wiki[1], please read it over and add new > content if you think it's missing something. > > If you like to help out, please send a note to svn-migrat...@lists.php.net > > Please forward this notice to any relevant mailinglist I may have missed. > Also, please limit all replies to this mail to the svn-migration@ list > to not spam everyone :) > > > Have fun and good luck all! > > -Hannes > > > [1] http://wiki.php.net/vcs/svnfaq Thomas Koch, http://www.koch.ro -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Socket Timeout Documentation
On Thu, Jul 2, 2009 at 01:01, Brian A. Seklecki wrote: > All: > > Perhaps we should clarify the socket tuneables such as: > > ; Default timeout for socket based streams (seconds) > default_socket_timeout = 60 > > These are slightly ambiguous. e.g., we should clarify connect() > timeouts v.s. "idle" timeouts. Anyone that knows the answer to this? > There are at least a dozen tickets open related to timeout behavior and > a lot of the confusion results of ambiguity in the variable naming > convention and documentation. Could you post the ones you know of here please? -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
+1 -- Pierre 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] Type hinting/casting request for vote
On Tue, Jul 7, 2009 at 02:52, Ilia Alshanetsky wrote: > The final patch is available here: http://ilia.ws/patch/type_hint_53_v2.txt > The test suit is available here: http://ia.gd/patch/type_hint_tests.tar.bz2 +1 -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
Ilia Alshanetsky wrote: > I would like to ask all developers to voice their opinions of whether it > makes sense to add this to 5.3 or to throw it away (either one is fine > btw). To keep the process simple & flamewar free, please restrict > yourself to +/- (1/0), next week monday I'll run a tally of the votes > and based on the result we can determine how to proceed further. +1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Type hinting/casting request for vote
+1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
+1
[PHP-DEV] [HEADSUP] Commit freeze (moving to SVN)!
Hi all The time has come that we move to SVN and the switch flipping will be happening next Friday (July 10th, 2009)! There will be a total cvs.php.net lockdown as of late Thursday, with svn.php.net replacing it ! The fire department (which needs more volunteers!) will be working through the weekend to extinguish fires that will break out due to the transition. A (very light) FAQ is on the wiki[1], please read it over and add new content if you think it's missing something. If you like to help out, please send a note to svn-migrat...@lists.php.net Please forward this notice to any relevant mailinglist I may have missed. Also, please limit all replies to this mail to the svn-migration@ list to not spam everyone :) Have fun and good luck all! -Hannes [1] http://wiki.php.net/vcs/svnfaq -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
On Mon, 6 Jul 2009, Ilia Alshanetsky wrote: > Last week or so there was a fairly detailed discussion on the internals list > regarding type hinting based on my original patch. Since then the patch has > been revised to address the major concerns that were identified (breakage of > binary compatibility) as well extended with additional functionality (object > hint, type casting, reflection support, etc...). > > The final patch is available here: http://ilia.ws/patch/type_hint_53_v2.txt > The test suit is available here: http://ia.gd/patch/type_hint_tests.tar.bz2 > > I would like to ask all developers to voice their opinions of whether it makes > sense to add this to 5.3 or to throw it away (either one is fine btw). To keep > the process simple & flamewar free, please restrict yourself to +/- (1/0), > next week monday I'll run a tally of the votes and based on the result we can > determine how to proceed further. +1 Derick -- http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org twitter: @derickr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
