Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

On 05/31/2011 11:52 AM, Sean Coates wrote: > I'm one of the people who've brought it up on Twitter. Today's discussion > seems to have earned some traction, which is a step in the right direction, I > believe. > >> I would prefer (as Rasmus pointed out) not

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

and b of course the middle case is not valid json and then things break down a bit. If we are going to support full json and then not be completely compatible, why use the json syntax at all. And not supporting associative arrays in the syntax is not an option. -Rasmus -- 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)

istinguish an associative array from an object makes it a problematic choice for a native syntax in PHP. -Rasmus -- 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 05/31/2011 02:45 PM, Ilia Alshanetsky wrote: > Rasmus, > > Don't you think having support for both ['a':1, 'b':2] and {'a':1, > 'b':2} would create confusion? Not if we present this as native json support in PHP. Then we have to support

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

ll project. This short syntax for arrays is probably the most requested PHP feature right now and we have a working patch that doesn't break any existing code so the effort involved is minimal. If you have a working patch that solves the Unicode issues, by all means, show us. -Rasmus -- PHP

Re: [PHP-DEV] RFC: Zend Signal Handling

n't know of any. Are there any issues with this change (BC, etc.)? There could be some weird interactivity issues with certain environments, but the patch takes care of most issues and I think the added stability this gives opcode caches is worth the minor risk. -Rasmus -- PHP Internals - PHP

Re: [PHP-DEV] Re: RFC: Short syntax for Arrays (redux)

On 05/31/2011 05:42 PM, dukeofgaming wrote: > I'm afraid that if ":" is associated with the JSON interop argument and the > later is discarded then ":" will be discarded too, much like what happened > with the echo shortcut (" of JSON interop could be taken to another RFC and get less noise and be

Re: [PHP-DEV] Re: RFC: Short syntax for Arrays (redux)

cess could really benefit from getting this type of feedback. I think it is well understood that PHP internals discussion happens on this internals mailing list. It is not a restricted list in any way. Anybody is able to participate here if they want their voice heard. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Bundling "modern" extensions

h2 is simple enough that an extension really isn't needed for it. OAuth1 was painful and the extension helped a lot. But all the painful bits that the extension takes care of are gone in OAuth2. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Bundling "modern" extensions

the way, gets very little attention. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Bundling "modern" extensions

On 06/05/2011 09:06 AM, Reindl Harald wrote: > Am 05.06.2011 13:58, schrieb Rasmus: >> On 06/05/2011 08:50 AM, Reindl Harald wrote: >>>> Also some exts are simply not used anymore or do not have active >>>> developers >>> >>> but they compile

Re: [PHP-DEV] 5.4 moving forward

;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

Re: [PHP-DEV] Re: [PHP-WIN] Re: [PHP-DEV] Windows builds

a nice separation between the two, so you don't need to match build environments there either. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] php-5.4.0 and apache-1.3

On 06/10/2011 06:31 AM, Karl Pflästerer wrote: > Hi, > some people (like me) still have to use Apache 1.3; I can't compile > PHP-5.4 with Apache-1.3, because of a change in revision 305276. Applied, thanks. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsu

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

f code would work perfectly for them. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

On 06/16/2011 11:40 AM, Pascal COURTOIS wrote: > Le 16/06/2011 12:31, Rasmus a écrit : >> On 06/16/2011 11:03 AM, Pascal COURTOIS wrote: >>> If you followed the thread you have seen the reduced test case is >>> VERY short and the ONLY constructions involved are user f

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

On 06/16/2011 12:42 PM, Rasmus wrote: > On 06/16/2011 11:40 AM, Pascal COURTOIS wrote: >> Le 16/06/2011 12:31, Rasmus a écrit : >>> On 06/16/2011 11:03 AM, Pascal COURTOIS wrote: >>>> If you followed the thread you have seen the reduced test case is >>>

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

agree, in order to leak 128M or whatever it was he said, it is unlikely that it is due to this. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Huge Pages

ugs: https://bugs.php.net/70984 https://bugs.php.net/71272 https://bugs.php.net/71355 This is very much an expert feature that we need to document better and people should know what they are stepping in when they turn this feature on. -Rasmus

[PHP-DEV] Annotated PHP 5->7 extension diff

r how to handle annotating it? We could turn it into a fake PR and mark it up using github's PR comments. But is there something more suited for this out there? -Rasmus signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] Annotated PHP 5->7 extension diff

On Feb 5, 2015, at 17:41, "guilhermebla...@gmail.com" wrote: > > Hi Rasmus, > > Thanks for the highlight. > My biggest concern about all this breakage done for NG could somehow be > minimized by providing possible alternate implementations that could work >

Re: [PHP-DEV] [VOTE] Scalar Type Hints

On 02/07/2015 05:03 PM, Pavel Kouřil wrote: > I'm wishing more and more that the RFC doesn't pass (even though I'd > LOVE to have typehints in PHP as a userland developer) and someone > else will make a better version of typehints RFC for PHP 7, because > this one feels really like you took an ok-

Re: [PHP-DEV] [VOTE] Scalar Type Hints

; not the whole file. Well, no, not the remainder of the file either since it can be switched again. It only affects the part of the file between declares if there is a second one. -Rasmus signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] [VOTE] Scalar Type Hints

ll fear that people are going to want to be enable strictness everywhere and then they will quickly learn that they better cast stuff to be safe which makes the whole thing rather pointless. And I feel pretty sorry for the Drupal folks. That list of 1000+ instances of their String class is going to suck to fix. -Rasmus signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] PHP 7 snapshots?

On 02/12/2015 01:39 PM, Jacob Bednarz wrote: > Hi Internals, > > Late in January Rasmus sent out an email to test the PHP 7 build. I've > recently completed this with a few of our applications locally however > now I am looking to test these changes on one of our is

Re: [PHP-DEV] [VOTE] Big Integer Support

ty much have to vote for the implementation as well. Every feature that requires significant work puts more pressure on a small group of developers and takes their time away from working on stabilizing the existing code base. My no vote is based on looking at the implementation, the size of the patch

Re: [PHP-DEV] Switch jumptable optimization

On 02/16/2015 03:04 PM, Bob Weinand wrote: > I'd like to show you my recent work on a jumptable optimization for switches. > > https://github.com/php/php-src/pull/1048 > > > It is a fully transparent optimization of switches, by putting a new > ZEND_SW

Re: [PHP-DEV] Switch jumptable optimization

On 02/16/2015 03:47 PM, Bob Weinand wrote: >> Am 17.02.2015 um 00:30 schrieb Rasmus Lerdorf > <mailto:ras...@lerdorf.com>>: >> >> On 02/16/2015 03:04 PM, Bob Weinand wrote: >>> I'd like to show you my recent work on a jumptable optimization for >>

Re: [PHP-DEV] Reviving scalar type hints

an internal resource id as if it was a valid number to be formatted without the slightest notice or warning anywhere that something is wrong in the code. This is my fear with this approach. People will start littering their code with casts and it will hide real bugs which is the complete opposite of what motivated this in the first place. Without more thought into how we properly deal with internal/extension code I don't really understand how so many people foresee this to work perfectly in the real world. -Rasmus signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] Reviving scalar type hints

On 02/16/2015 05:57 PM, Sara Golemon wrote: > On Mon, Feb 16, 2015 at 4:52 PM, Rasmus Lerdorf wrote: >> I still disagree strongly that it serves everyone's needs. The internal >> API and APIs provided by extensions are completely messed up by this >> approach. Usersp

Re: [PHP-DEV] Reviving scalar type hints

is also converted to 1 in https://74.125.28.104";); curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, ["I have no idea what I am doing"]); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); echo curl_exec($ch); echo curl_error($ch); return "beer"; } hh_client report

Re: [PHP-DEV] Reviving scalar type hints

(Z_BVAL_PP(zvalue) == 1) { The runtime could say, hey, I am in strict mode here and you are passing me an array of strings which I am coercing to a boolean. Not cool. -Rasmus signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] Reviving scalar type hints

On 02/17/2015 08:38 AM, Sara Golemon wrote: > On Tue, Feb 17, 2015 at 12:22 AM, Rasmus Lerdorf wrote: >> Please correct me here if I somehow ran these incorrectly. I did put >> some deliberate type errors into my userspace code and hh_client caught >> those nicely, so it seem

Re: [PHP-DEV] Scalar Type Hints v0.4

On 02/17/2015 04:35 PM, Nikita Popov wrote: > I don't buy into Rasmus arguments about internal functions. They concern > one particular edge case (int->float coercion) and I doubt they have much > relevance if applied to codebases with pervasive use of typehints (where > you ca

Re: [PHP-DEV] Scalar Type Hints v0.4

not needed. I guess the > next one would be (int -> bool), and the rest would follow. We need to keep in mind that int->float isn't technically lossless. We have a 53-bit IEEE754 mantissa to take account for here, so it is only lossless for values below 36028797018963966 or so. -Rasmus signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] Digit separators for numeric literals

ast one looks best to me, but we'd need a team of people working in shifts to answer the, "How do I type this?" question. -Rasmus signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] Digit separators for numeric literals

On 02/18/2015 11:21 PM, Rick Widmer wrote: > On 2/18/2015 7:44 PM, Rasmus Lerdorf wrote: >> Now if we went into Unicode territory, we could do it. eg. >> >>my_func(1 999 999) U+1680 (although it looks too much like a -) >>my_func(1 999 999) U+205F (mathem

Re: [PHP-DEV] Digit separators for numeric literals

On 02/18/2015 11:49 PM, Michael Wallner wrote: > On 19/02/15 03:44, Rasmus Lerdorf wrote: > >> but _999_ would need to work as well and _ is a valid char in a constant >> so you can have a constant named _999_. >> > > Why would we need to support the underscore in

Re: [PHP-DEV] Reviving scalar type hints

On 02/20/2015 09:39 AM, Anthony Ferrara wrote: > I think if anything, the appearance of Hack (and its adoption) show > that people want static typing, at least to some level... To be perfectly transparent here though, you should mention that your proposed RFC goes well beyond the strict typing tha

Re: [PHP-DEV] Reviving scalar type hints

On 02/20/2015 10:52 AM, Josh Watzman wrote: > On Feb 20, 2015, at 10:30 AM, Rasmus Lerdorf wrote: >> Hack examples all using > >> echo number_format('1000'); >> echo htmlspecialchars(1000); >> echo md5(1000); >> >> These are all fine both a

Re: [PHP-DEV] A different user perspective on scalar type declarations

t would require force-casts to make this backend code work in strict mode and then we are back to square one. -Rasmus signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] Consistent function names

tly recognizable to you. As I normally explain to people, there is vertical consistency here, not horizontal consistency. I understand how people who don't have a background in the underlying libraries might wish for a different API and horizontal consistency across disparate extensions, but simply adding a bunch of aliases that have no basis in anything doesn't help anybody. -Rasmus signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] Consistent function names

atal. > (Security should be evaluated by "how difficult to make mistakes", not "how > easy to > fix mistakes" generally. IMHO) > > I made list of rename candidates > https://wiki.php.net/rfc/consistent_function_names#list_of_functions_to_be_renamed > If

Re: [PHP-DEV] Consistent function names

On 03/04/2015 08:26 AM, guilhermebla...@gmail.com wrote: > @Rasmus: > > I don't see what's the problem of aliasing functions for the next 1-2 > majors, deprecate the inconsistent one in the following and remove later. As far as I am concerned str_len() would be the in

Re: [PHP-DEV] Consistent function names

On 03/04/2015 08:25 PM, Yasuo Ohgaki wrote: > Hi Rasmus, > > On Thu, Mar 5, 2015 at 1:46 AM, Rasmus Lerdorf <mailto:ras...@lerdorf.com>> wrote: > > On 03/04/2015 08:26 AM, guilhermebla...@gmail.com > <mailto:guilhermebla...@gmail.com> wrote: > &g

Re: [PHP-DEV] Consistent function names

t; valid names. Do you like this proposal? Nope, I don't. PHP is over 20 years old at this point and the PHP names for the functions are one and the same as the IEEE names. I see absolutely no reason to create a new class of "PHP" names. -Rasmus signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] Is OpCache enabled by default in php 5.5 and later or not?

d to install the opcache package. Presumably the way Centos has created the rpm it will add the appropriate magic ini settings and you will see opcache listed in your phpinfo() output after installing that package. And ZendOptimizer is the same as Opcache in this context. -Rasmus signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints

be permitted to be booleans. If a specific float can be > converted to an int, and all ints can be converted to booleans, then > the transitive property should hold for that float to a bool. The problem there is what does "without dataloss" mean? At which precision do you consider

Re: [PHP-DEV] [RFC][PRE-VOTE] Reserving More Types in PHP 7

net/unsub.php >> > > This is a solid plan. Vote this and everyone should +1 it, so if this > scalar squabble results in a a 0-0-0 score we can at least add scalars > later. This is not quite that obvious I don't think. If https://wiki.php.net/rfc/context_sensitive_lexer isn't ready in time for 7.0 and we don't need to reserve these for one of the STH RFCs then we should hold off and do it alongside the context sensitive lexer change or we are going to needlessly break a ton of code including Drupal8: https://github.com/drupal/drupal/blob/8.0.x/core/lib/Drupal/Component/Utility/String.php#L15 -Rasmus signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC][PRE-VOTE] Reserving More Types in PHP 7

On 03/15/2015 09:41 AM, Niklas Keller wrote: > Rasmus, the context sensitive lexer doesn't change anything for Drupal. > Support for class names has been dropped, > see https://wiki.php.net/rfc/context_sensitive_lexer#rejected_features Yes, I realize that. I just mentioned Drupal as

Re: [PHP-DEV] RE: [PHP-CVS] com php-src: Enable GCC global register variables if available: Zend/Zend.m4 Zend/zend_execute.c

port for global register variables]) > +else > + HAVE_GCC_GLOBAL_REGS=no > +fi > +AC_MSG_RESULT(ZEND_GCC_GLOBAL_REGS) Dmitry, the perf boost of this is awesome, but is it completely safe? Won't a signal potentially overwrite a register variable here? Like on a timeout, for example? -Rasmus signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] [Q] Does PHP have a negative cache for file stat operations?

he stat cache. It is still going to stat on every single page load. It is only multiple identical stats within the same request that gets caught by the stat cache. -Rasmus signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] Proposal to delay 7.0 timeline

ings indefinitely. And I completely disagree that this isn't a 'real' major version. -Rasmus signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] Use "ropes" for string concatenation

t is a good change. The only question is about implementation stability and frankly we only have a handful of people able to make an intelligent call on code at this level. If one of those people were to raise a flag, and so far they haven't, then we might pause, otherwise full steam ahead. -Rasmus signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] Deprecate setlocale?

he rug out from under people using it, we should take a look at fixing the problems associated with it instead. -Rasmus signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] Deprecate setlocale?

hat doesn't mean there is anything wrong with implementing thread-local setlocale for our threadsafe builds, and we should definitely fix any in-process setlocale interference issues, but the thread safety part of it just doesn't seem like something very many people are going to care about. Why do you? -Rasmus signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] Re: Maintaining PHP LDAP module

https://github.com/php/php-src/pull/652 > > That’s when I thought the php-ldap extension might need a new maintainer. The ldap code could definitely use some attention. You have git access now. Could you also go through the bug db and see if you can address some of the longstanding reported i

[PHP-DEV] Re: [PHP-CVS] com php-src: Add targets to simplify building PHP with FDO (Feedback Directed Optimisation) PHP should be built with the folowing steps:: Makefile.global configure.in

PHP might be even slower. Whoa, really 10%? I know there is AutoFDO coming in gcc 5.1 and I didn't think this was really practical until then. Perhaps it is. I wonder if this will spur php-wordpress, php-drupal and php-mediawiki tuned builds? -Rasmus signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] Request for php-src karma

f I can commit obvious and > uncontroversial fixes directly instead of making PRs first. Done and thanks for all your help and patience on bugs.php.net. -Rasmus signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] PHP 7.0.0alpha1 Released for Testing!

ortant sign :) You can get even more speed by compiling with --enable-opcache-file and then in your php-cli.ini add: opcache.enable_cli=1 opcache.file_cache=/var/tmp opcache.file_cache_only=1 Then every time you run composer it won't have to recompile everything. -Rasmus signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] PHP 7.0.0alpha1 Released for Testing!

> On Jun 13, 2015, at 14:54, Jan Ehrhardt wrote: > > Rasmus Lerdorf in php.internals (Fri, 12 Jun 2015 13:13:16 -0700): >> You can get even more speed by compiling with --enable-opcache-file and >> then in your php-cli.ini add: >> >> opcache.enable_cli=1

Re: [PHP-DEV] PHP-FPM: How to clear the realpath cache on deployment?

dule to do it: https://github.com/etsy/mod_realdoc Then there is never a question of needing to clear any caches at the PHP level. See: https://codeascraft.com/2013/07/01/atomic-deploys-at-etsy/ for a more indepth explanation. -Rasmus signature.asc Description: OpenPGP digital signature

[PHP-DEV] hasType() for internal function parameters?

e->getMessage()."\n"; } The output is: Parameter #0 [ string $str ] (1) Parameter #0 [ $str ] () Argument 1 passed to ustrlen() must be of the type string, integer given, called in /home/rasmus/prop.php on line 11 strlen() expects parameter 1 to be string, integer given That i

Re: [PHP-DEV] hasType() for internal function parameters?

write a script to generate the bulk of it. I just don't like the fact that a parameter can raise a type error when it claims to not have a type. It makes writing static analysis and other type checking tools much more complicated. -Rasmus signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] hasType() for internal function parameters?

On 06/21/2015 03:40 PM, Kalle Sommer Nielsen wrote: > Hi > > 2015-06-21 20:58 GMT+02:00 Rasmus Lerdorf : >> Or we bite the bullet and fix the arginfo everywhere to make it >> consistent. It wouldn't be that hard to write a script to generate the >> bulk of it. &g

Re: [PHP-DEV] hasType() for internal function parameters?

a little script which generates it from the doc-comments in the code. I think the easiest way to do it is to first go through the file and check the "{{{ proto" comments to make sure the optional args are denoted correctly and no args are missing. To run it: script/dev/genarginfo.

Re: [PHP-DEV] hasType() for internal function parameters?

On 06/22/2015 05:11 AM, Dmitry Stogov wrote: > Hi Rasmus, > > Your latest changes broke more than 100 tests. > Sorry, but I had to revert your commits and related Bob's fixes. > You may find them in internal-arg-info branch. > > Please, don't do experiments on the

Re: [PHP-DEV] hasType() for internal function parameters?

gt; difference. Right, behaviour shouldn't change, but couldn't we also make it so that arginfo for internal calls is only used by reflection? We can do all the type checking we need right in ZPP as we do now. Let's just ignore arginfo entirely for these calls. -Rasmus signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] hasType() for internal function parameters?

On 06/22/2015 03:00 PM, Dmitry Stogov wrote: > > > On Mon, Jun 22, 2015 at 8:35 PM, Rasmus Lerdorf <mailto:ras...@lerdorf.com>> wrote: > > On 06/22/2015 01:27 PM, Dmitry Stogov wrote: > > Actually, when you added type hints, php compiler stoppe

Re: [PHP-DEV] hasType() for internal function parameters?

m very broken to the point where I wonder if we shouldn't just disable reflection on internal functions entirely since the arginfo is so woefully incomplete. Plus the double-checking is super messy. -Rasmus signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] hasType() for internal function parameters?

ful there. I suppose so, but this seems like a relatively minor level of BC breakage especially for a major version bump. -Rasmus signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] New PHP SAPI for Nginx

d more robust. You can also already do nginx to php-fpm without any network overhead by using a unix domain socket. -Rasmus signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] PHP7 and types

ng ones. It may not be feasible to do in an efficient manner. A static analyzer can get away with catching 95%. A core language feature can't. Having to do these the type check on assignment will likely require some significant changes to the engine. -Rasmus signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] PHP7 and types

On 07/12/2015 05:12 PM, Rasmus Lerdorf wrote: > On 07/12/2015 12:37 PM, Larry Garfield wrote: >> I don't know why we're even talking about IDEs here. IDE >> auto-completion isn't the point, anymore than it was the point for >> scalar type hints or return type h

Re: AW: [PHP-DEV] PHP7 and types

mode that finds these bugs without bogging down the runtime with thousands of type checks. -Rasmus signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] Introductions

t unable to ensure that every > component they plug in to their website is coded with security-in-mind. > > I look forward to working with you all to make PHP a better product for PHP > developers and website owners! Sounds great. There is some intro info along with the git account req

Re: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7

a RM gives me > the green light to do so. An error on this makes sense to me too and it doesn't seem like much of an issue to make this change now. But yes, it is the RM's final call. -Rasmus signature.asc Description: OpenPGP digital signature

[PHP-DEV] Re: Patch: getters/setters syntax Implementation

2011/12/4 Clint M Priest : > Updated patch w/o white-space: http://www.clintpriest.com/patches/accessors_v1.patch > > In the end it is a relatively simple patch. The new syntax effectively creates internal functions on the object and the system looks for those functions and calls them at the appro

Re: [PHP-DEV] Re: Patch: getters/setters syntax Implementation

On Tue, Dec 6, 2011 at 3:45 AM, Christian Kaps wrote: > Hi, > > I also find this syntax confusing and I think it has a huge WTF factor. > > Some thoughts about the syntax: > - At the first glance, it isn't clear which visibility the getter or > setter has > - The extra indentation level makes the

Re: [PHP-DEV] Patch: getters/setters syntax Implementation

etters/setters actually compile down to two method implementations, while implemented getters/settings do the same, substituting "value" for whatever is required to access the auto-implemented backing field. On Tue, Dec 6, 2011 at 9:26 AM, Will Fitch wrote: > > On Dec 6, 2011, at

Re: [PHP-DEV] Patch: getters/setters syntax Implementation

operty zval and bitmap added to the zend_uchar type identifying it as > an accessor I'm saying be creative - don't just implement something > halfway for the sake of getting it done. > > > On Dec 7, 2011, at 12:50 PM, Rasmus Schultz wrote: > > >> if w

[PHP-DEV] Phalanger

. What are the benefits of the C codebase over Phalanger? I understand the licensing may be an issue. It may be the argument that outweighs everything else, but I'm curious to hear what else would keep you from moving to Phalanger? Thanks! - Rasmus Schultz

Re: [PHP-DEV] Phalanger

On 12/08/2011 03:28 PM, Rasmus Schultz wrote: > Don't take this the wrong way, I'm merely trying to provoke your thoughts a > bit with this e-mail! :-) > > Has it occurred to anyone, to abandon the official PHP codebase and adopt > Phalanger instead? > >

Re: [PHP-DEV] Phalanger

On 12/08/2011 03:53 PM, Rasmus Lerdorf wrote: > This is a complete non-starter. The bulk of PHP users are on > non-Windows, especially Linux, and Mono performance on Linux is really > not good. Last time I checked it was an order of magnitude slower on > Linux compared to the same hard

Re: [PHP-DEV] Is Bug #34972 (no non-blocking on STDIN on Windows) going to be fixed?

It is non-trivial to implement on Windows. It is more of a feature request than a bug. UNIX supports non-blocking stdin natively, Windows doesn't. A Windows guy would need to write a compatibility layer to get this to work and we don't have very many Windows guys around. -Rasmus

Re: [PHP-DEV] Phalanger

et under .NET on Windows. Does that mean it's going to be slower under Mono than the Zend VM? I would say not likely. But I guess we'll have to wait for a Linux PHP vs Linux Phalanger benchmark to know for sure... - Rasmus On Thu, Dec 8, 2011 at 7:16 PM, Rasmus Lerdorf wrote: > O

[PHP-DEV] APC caching identical files multiple times

Hello Folks, We're hosting an increasing number of Drupal (ick) sites on our servers, and while going over the diagnostic screen for APC, we noticed that identical files are being cached multiple times. For example, "user.module" is cached 3 times for 3 sites. I've seen other people asking this

Re: [PHP-DEV] Return Type Hinting for Methods RFC

he effort in the correct place and doesn't encourage this type of coding. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Return Type Hinting for Methods RFC

On 12/22/2011 10:51 AM, Sebastian Bergmann wrote: > Am 22.12.2011 19:41, schrieb Rasmus Lerdorf: >> This is not a step forward. If the author of age_check() really doesn't >> want to accept type-juggled arguments, then it is easy enough to do a >> strict type check in

Re: [PHP-DEV] Return Type Hinting for Methods RFC

On 12/22/2011 11:18 AM, Will Fitch wrote: > On Dec 22, 2011, at 1:41 PM, Rasmus Lerdorf wrote: > >> On 12/22/2011 07:08 AM, Keloran wrote: >>> i would love to see this expanded aswell (the way type hinting on function >>> variables was supposed to be), so that i

Re: [PHP-DEV] Return Type Hinting for Methods RFC

uage, so you end up not catching these until runtime which is obviously sub-optimal. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Return Type Hinting for Methods RFC

On 12/22/2011 11:49 AM, John Crenshaw wrote: > From: Rasmus Lerdorf [mailto:ras...@lerdorf.com] > >> How is that hard? >> >> function age_lookup($age) { >> return $coll->find(array('age' => (int)$age); >> } >> >> but aga

Re: [PHP-DEV] Re: another fix for max_input_vars.

ion it. Since it is one of these remotely-triggered errors that you can't program around, it should probably be suppressed when display_errors is on. There is another precedence for this, but I am drawing a blank on where else we did this right now. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: another fix for max_input_vars.

On 01/04/2012 11:54 AM, Nikita Popov wrote: > On Wed, Jan 4, 2012 at 8:50 PM, Rasmus Lerdorf wrote: >> Since it is one of these remotely-triggered errors that you can't >> program around, it should probably be suppressed when display_errors is >> on. There is another pre

Re: [PHP-DEV] Re: another fix for max_input_vars.

On 01/04/2012 12:19 PM, Reindl Harald wrote: > > > Am 04.01.2012 21:07, schrieb Paul Dragoonis: > >> I agree with Rasmus here. A lot of people keep display_errors >> on, even when they shouldn't. > > it is not the job of a programming language stop admins

Re: [PHP-DEV] Re: another fix for max_input_vars.

.. But that is precisely why this is a special case. Even if you do ini_set('display_errors', 0) in your code this message will still be displayed. Although, display_startup_errors is off by default and hopefully this one falls under that setting. I didn't test it, but if it does

Re: [PHP-DEV] Re: another fix for max_input_vars.

0". > If somebody has the time to double check/test this, it would be nice. Right, like I said in my previous message, if this is caught by display_start_errors, I am ok with it. We need the default/no php.ini file case to not leak information like this. -Rasmus -- PHP Internals - PHP Ru

Re: [PHP-DEV] Re: another fix for max_input_vars.

an still send 1M post vars in a single POST if you just nest them in a 1000x1000 2d array. Of course, this is likely going to hit the post_max_size limit, although many sites that do file uploads will have cranked that way up. -Rasmus -- PHP Internals - PHP Runtime Development Mailing Lis

Re: [PHP-DEV] Re: another fix for max_input_vars.

On 01/04/2012 01:48 PM, Rasmus Lerdorf wrote: > On 01/04/2012 01:27 PM, Stas Malyshev wrote: >> Hi! >> >>> Right, like I said in my previous message, if this is caught by >>> display_start_errors, I am ok with it. We need the default/no php.ini >>> f

Re: [PHP-DEV] Re: another fix for max_input_vars.

On 01/04/2012 08:13 PM, Laruence wrote: > On Thu, Jan 5, 2012 at 5:56 AM, Rasmus Lerdorf wrote: >> On 01/04/2012 01:48 PM, Rasmus Lerdorf wrote: >>> On 01/04/2012 01:27 PM, Stas Malyshev wrote: >>>> Hi! >>>> >>>>> Right,

  1   2   3   4   5   6   7   8   9   10   >