Re: [PHP-DEV] [RFC][VOTE] Flexible Heredoc and Nowdoc Syntaxes

Hi! > From the body of the RFC: > > "To enable for the closing marker to be indented, ... The indentation > of the closing marker dictates the amount of whitespace to strip from > each line within the heredoc/nowdoc" Yes, that's what the RFC says. But the voting question only mentions indenting

Re: [PHP-DEV] [RFC][VOTE] Flexible Heredoc and Nowdoc Syntaxes

Hi! > Voting has now started on the flexible heredoc and nowdoc syntaxes RFC[1]. > > > Voting will be open for 2 weeks (until November 15th). Something I am missing here. RFC is talking about removing indents from heredoc text, but the vote says "Allow for the closing marker to be indented?"

Re: [PHP-DEV] json(Raw)Serializable?

Hi! > It's not terribly unreasonable IMO, but before I just writeup the RFC > as described (jsonRawSerialize taking preceedence over jsonSerialize), > I thought I'd ask for opinions on the specifics. > > In psuedo-code: > > if (is_object($obj)) { > if ($obj implements JsonRawSerializable) { >

Re: [PHP-DEV] Session extension cannot be used in a loop/CLI since 7.2

Hi! > I'm having a hard time fixing Symfony's tests suite to 7.2 because of the > added warnings+ini_set-rejections in the Session module. > > Testing the session on the CLI is not possible anymore without starting one > PHP process per test case. Why not, you may say. That doesn't sound good,

Re: [PHP-DEV] PCRE2 support

Hi! > I'd suggest to integrate PCRE2 into 7.3. Will go for an RFC, if necessary. Yes, RFC would be nice. Does the move mean 7.3 could not be built on environments without pcre2? May be OK, but we'll need to make that clear. There may also be other aspects of the code that we need to pay

Re: [PHP-DEV] Is reference counting necessary for a PHP implementation?

Hi! > Is this statement correct? If I understand correctly many PHP projects > depend on the deterministic firing of `__destruct()` function to cleanup > SQL transactions or connections and so forth. Yes. But, strictly speaking, you do not have to use specifically refcounting - i.e. having some

Re: [PHP-DEV] [RFC] Pre-draft for PipeOp v2

Hi! > After discussion with Levi and others who suggested a simpler > approach, I'd like to offer > https://github.com/php/php-src/compare/master...sgolemon:pipe2 as an > alternate possibility. I am still feeling it is a bit weird to do things that way, but other than that (which is just my

Re: [PHP-DEV] Progress or just 'a mess'?

Hi! > Having established that the only characters that are case-insensitive in > PHP7 ... the unicode basic latin set ... the discussion SHOULD be on > either expanding that to cover all case folding or simply removing this > rather limited case? Why? Does anybody seriously need Russian case

Re: [PHP-DEV] Progress or just 'a mess'?

Hi! > picking up on the base problem? Just what character set is PHP7 designed > to work with. What do you mean by "work with"? > For PHP8 is it not time to lay out a similar set of rules as provided by > SQL and identify just what 'case-insensitive' means and where it does apply? I'm not sure

Re: [PHP-DEV] Deprecate and remove case-insensitive constants?

Hi! > If they were truly case-insensitive, I might agree. However, as I've > mentioned but will reiterate, they're not. They're ASCII case > insensitive, and that's a long cry from real case-insensitivity. PHP > 6 was planning to make case-insensitivity real but obviously that's > dead and

Re: [PHP-DEV] Deprecate and remove case-insensitive constants?

Hi! > Does deprecating case insensitive constants clear the bar of > 'substantial gains to be had'? Personally, I don't think so. Yes, a > marginal edge case that took almost 20 years to surface would become > marginally better (and that edge case is arguably We could fix that case by banning

Re: [PHP-DEV] [RFC] Deprecate the extract function in PHP 7.3

Hi! >> This was a request for feedback > > then you should withstand the feedback! Request for feedback does not mean consent for abuse. You can criticize without being offensive. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe,

Re: [PHP-DEV] [RFC] Deprecate the extract function in PHP 7.3

Hi! On 9/15/17 2:20 PM, ilija.tov...@me.com wrote: >> no, as there is no special risks > > There certainly is. No other function (as far as I’m aware) mutates your > local symbol table. This means you need to know exactly what symbols are Sure, because this is the function to mutate your local

Re: [PHP-DEV] [RFC] Deprecate the extract function in PHP 7.3

Hi! > Dangerous meaning that if given untrusted input someone could mess with > the behaviour of your code. There are risks and benefits to every Same as many other functions. Given untrusted input, unlink() could delete files on your hard drive, and file_put_contents() could overwrite your data

Re: [PHP-DEV] [RFC] Deprecate the extract function in PHP 7.3

Hi! > As a second parameter the `extract` function takes some options to > make this function less dangerous, like `EXTR_SKIP` that I'd start with specifying what exactly is "dangerous" in this function. So far I don't see any specific danger. You can shoot yourself in the foot, so you can with

Re: [PHP-DEV] Deprecate and remove case-insensitive constants?

Hi! > It seems to me that this would miss the point, namely to introduce some > consistency, and to be able to If working code would be broken, nobody needs "consistency". I've built tons of software, and never ever any single client asked me "but do you have 'constistency'? Surely, I'm not

Re: [PHP-DEV] [RFC][Discuss] Increase non-syntax runtime-impacting RFC voting threshold to 60%

Hi! > I would also explicitly note that the voting threshold applies to the > primary RFC vote only, while secondary votes are simple majority votes. This sounds like a good compromise. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To

Re: [PHP-DEV] Deprecate and remove case-insensitive constants?

Hi! > +1 on doing this. I can understand having case-insensitive constants, but > having both case-sensitive and case-insensitive at the same time is weird > and rather useless. I imagine the only reason why this "feature" exists in > the first place is to support arbitrary casing for

Re: [PHP-DEV] Deprecate and remove case-insensitive constants?

Hi! > case-insensitive constant. This feature appears to potentially result > in confusion, and also causes bugs as shown in > . See an example created by Nikita to see > some probably unexpected behavior: . The latter case probably should be

Re: [PHP-DEV] [VOTE] UUID

Hi! > That would be fine and appropriate. The RFC targets 7.3. Having a > discussion and vote in March gives plenty of time for getting it into > 7.3 > > Cancelling a vote just to avoid an RFC being rejected is (imo) playing > slightly fast and loose with the rules. I agree. I think the RFC

Re: [PHP-DEV] [VOTE] Same Site Cookie RFC

Hi! > additional argument to these three functions. The second implementation > suggestion is to allow an array of options in which all the cookie > options will be moved into. More details are to be found in the RFC. Something not clear to me on the second one - why lifetime/expiration is a

Re: [PHP-DEV] Unserialize security policy

Hi! > The two main points are: > 1. While it's true that if you're using unserialize() on untrusted input > you are most likely going to be vulnerable due to object injection, it may > be quite hard for an attacker to exploit this for closed source Objects are not the problem (unless it's

Re: [PHP-DEV] Re: WDDX serialization and security

Hi! > IMHO, implementing support for objects has been a most unfortunate > decision, because WDDX was indeed not designed for that > (). Considering > https://bugs.php.net/bug.php?id=75044 makes the situation worse. > Agreed, and it was also

Re: [PHP-DEV] Stop Exceptions capturing object references for trace arguments

Hi! > My only concern is if anyone is using this data for anything other than > debugging - e.g. if they were somehow extracting extra context about the > exception by traversing the backtrace to a particular point and grabbing > the arguments. That feels like a horrible hack to me, but that

Re: [PHP-DEV] Stop Exceptions capturing object references for trace arguments

Hi! > The "args" part of this contains full object references to anything that > happens to have been a function argument in the stack, and causes two > problems: I think it makes sense to make exception not to collect args. In fact, I think this may also be one of rare cases where new ini

Re: [PHP-DEV] Unserialize security policy

Hi! > https://bugs.php.net/bug.php?id=75006 has been marked as a non-security > bug, with the justification that unserialize() should not be fed untrusted > input. While we do document that unserialize() shouldn't be used on > untrusted input, we have always treated these as security bugs in the

Re: [PHP-DEV] Changes to SuperGlobals for PHP 8

Hi! > My point was that if we were considering a compatibility break > anyway, we should look at separating out those common use cases into > something higher level. I'm completely in agreement with you here, except for "compatibility break" part. The good news is that you do not need any

Re: [PHP-DEV] Changes to SuperGlobals for PHP 8

Hi! > This is true within the context of the current "shared nothing" > design of PHP. There has been talk - and indeed existing > implementations - of a more event-based system, where this state > would no longer be naturally global in any sense. But as I That's fine - but in that design, you

Re: [PHP-DEV] Changes to SuperGlobals for PHP 8

Hi! > Sure it seems useful, but I see it more as a hack if you are just > writing to superglobals anyway, if you need to change something you > should do that with your own logic instead. That's what I said - you can always add a layer of indirection. But why? What is so sacred in those

Re: [PHP-DEV] Changes to SuperGlobals for PHP 8 (was: something about session_start...)

Hi! > I for one thing it makes a lot of sense to make superglobals > read-only, writing to them seems more like a hack anyway and should be > avoided I've seen scenarios where it is very useful. Sure, you can always build another layer of indirection and solve it this way, but it's just making

Re: [PHP-DEV] Re: Changes to SuperGlobals for PHP 8 (was: something about session_start...)

Hi! > I'd just like to add that if we were going to make BC-breaking changes > to superglobals in PHP 8, we might as well also get rid of the name > mangling on keys for $_GET, $_POST and $_REQUEST at the same time That's a good point. We definitely should get rid of this one, it adds absolutely

Re: [PHP-DEV] Changes to SuperGlobals for PHP 8 (was: something about session_start...)

Hi! > On a slight tangent, I consider $_SERVER to be a broken pile of > "we'll just shove this in here and hope for the best", and I will > oppose any attempt to convert it into an object which doesn't > reorganize its keys to be sane, documented, and as cross-platform as > the SAPI layer can

Re: [PHP-DEV] Size of release tarballs

Hi! > Lately there was a discovering about some files causing size growth > of the release tarballs > https://github.com/php/php-src/commit/469206c84e502e3e349655b802899d5e4d560f72 > . Usually we strive to keep tarballs as small as possible and avoid > disproportional growth of the size. This

Re: [PHP-DEV] array coalesce operator concept

Hi! > Code will error if a non-array value is passed through a looping feature. > For example, this code: > > > $foo = "abc"; > > foreach ($foo as $bar) { Looks like $foo??[] would work here. If $foo is something like false or null, that is. If it's not, this is probably a serious bug (why

Re: [PHP-DEV] OBJECT_OPERATOR vs. DOUBLE_COLON

Hi! > I think that using :: on a variable that contains an object should not > "fall back" to a static access on the object's class. Instead the > runtime should error out. Why should it not do what it does now? What would it achieve? I don't see any improvement in changing that - it may break

Re: [PHP-DEV] Exposing object handles to userland

Hi! > On 32-bit zend_long is a signed 32-bit int, so it can theoretically overflow, > while sizeof is same. Well, it's the same issue we having on representing any unsigned values, I guess. Since int<->uint in this case is one-to-one, should be ok to just use the negative nums, if they are used

Re: [PHP-DEV] Exposing object handles to userland

Hi! > No: In PHP 7 this is not possible, which is also why spl_object_hash() no > longer includes the handlers. Ah, I missed that part. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Exposing object handles to userland

Hi! > - Can two objects can have the same object id > but different object handlers? > (e.g. iterators of some built in classes?) > I'm not familiar enough with PHP's history to be sure. Yes, if extension using non-standard handlers is in use. > - Can the the largest object handle be

Re: [PHP-DEV] 7.2 behavior break, Bug #74836 isset on zero-prefixed numeric indexes in array broken

Hi! > > Please take a look at https://bugs.php.net/bug.php?id=74836 > > What is the best option to fix this? > > > The most consistent way, from my point of view - disabling zero-prefexed > numeric strings in all cases, but this is a new behavior break. I think this is very corner case, for

Re: [PHP-DEV] Binary (msgpack) serialize/unserialize

Hi! > PHP Session, http://php.net/manual/en/session.configuration.php#ini.session.serialize-handler ? > Memcache, Redis, etc - not configuring custom serializer. > Not sure about those, but don't see a problem adding custom handler. -- Stas Malyshev smalys...@gmail.com -- PHP Internals -

Re: [PHP-DEV] Binary (msgpack) serialize/unserialize

Hi! > Back in 2014 there was an informal proposal on the mailing list to replace > PHP serialization with an efficient binary (msgpack) format. Why replace? If you have it as an extension, can't people that want to use it just use it? I'm still not sure why we need to do anything in core that

Re: [PHP-DEV] [RFC] Unary null coalescing operator

Hi! > I think that `if ($_GET['x']?? === 1)` looks and feels a lot like `if > (@$_GET['x'] === 1)`... > > Yes, the latter has runtime performance issues and will still send > notices to error handlers and logs. But perhaps if we're going to > extend syntax, the syntax could be something along

Re: [PHP-DEV] Missing commits in 7.0 branch

Hi! > From the history it looks like you didn't push the 7.0 branch. > > See also the commit mail which only references 7.1 and master. > http://news.php.net/php.cvs/96748 Ok, I've re-added them to 7.0 and pushed it. Anatol, could you also add these to the release branch so that 7.0 would be

Re: [PHP-DEV] [RFC] [Discussion] Retry functionality

Hi! > The RFC that proposes adding retry functionality to the > `try/catch/finally` block is now officially "under discussion". > > https://wiki.php.net/rfc/retry-keyword To me, it looks like this belongs in userspace, not as a language keyword. I don't really see what it does that you can't do

[PHP-DEV] Missing commits in 7.0 branch

Hi! I've discovered something weird in 7.0 branch. There are two commits of a bugfix - https://github.com/php/php-src/commit/d1d002fc4dd25a80e20163b18880f40a445276e7 and https://github.com/php/php-src/commit/8c44d07fd485a8e8d62bc6e4fe14bec5493ebc58 - which I made, which are present in 7.1 and

Re: [PHP-DEV] Documentation (Doxygen)

Hi! >> But randomly introducing docs system without any explicit decision in an >> unrelated patch doesn't look like a good idea to me. >> > > Wow! This sounds like you think that I am trying to deliberately > sabotaging the PHP project. Quite the opposite is the case. I am simply Sorry if it

Re: [PHP-DEV] Implement formal process for run-tests.php refactor

Hi! > Is that worth a shot, do you think? Definitely. There's no reason also why it shouldn't work so failing tests in such scenario probably should be treated as bugs. A lot of tests also inherently parallel-safe - probably majority of them, though wouldn't claim I am 100% sure - so maybe

Re: [PHP-DEV] Class Naming in Core

Hi! > People are complaining over at Reddit [1] Isn't it what Reddit is for? ;) > I know that this is probably a topic nobody cares much about, at least > we did not end up in this kind of bikeshedding in the UUID discussion > thread, but it is after all an important question when designing a

Re: [PHP-DEV] Documentation (Doxygen)

Hi! > I used Doxygen in both PRs to document the code. Right now the code base > is lacking a lot of documentation, which, if done right, would greatly > improve accessibility of the code base. Well, the problem as I understand it is that we don't have Doxygen setup for docs generation. So,

Re: [PHP-DEV] [RFC] Enable strict_types checking for curl_setopt()

Hi! > I disagree. From the user's perspective it is argument typing. The Not really. Argument typing is when arguments have types. curl_setopt arguments do not have known types, they have business logic inside that says if argument X is equal to this, then argument Y must be of that type. It's

Re: [PHP-DEV] [RFC] Enable strict_types checking for curl_setopt()

Hi! > Because each option expects the value to be a specific type, it makes sense > to enforce these types in strict type checking mode. I'd therefore like to > propose that we introduce strict type enforcement inside curl_setopt() when > "declare(strict_types=1);" is being used. While it may

Re: [PHP-DEV] [7.2] Timetable

Hi! > Similarly, does it really make sense to have a new pre-release every two > weeks? I know that "we've always done it this way", but I'm not sure I see > the motivation behind it (or who the target audience for a biweekly release > is). I'd leave it to the RM, if nothing substantial changes

Re: [PHP-DEV] Re: Inconsistency in line numbers.

Hi! > behavior I wasn't aware of: https://3v4l.org/6fSRb In backtraces the call > is located on the line of it's last argument (in PHP 5.6 the line of the > closing ")"). Wouldn't it make more sense to use the starting line of the > call? That is, use the same lineno for INIT_FCALL and DO_FCALL?

Re: [PHP-DEV] PHP 7.2 Release Managers

Hi! > I keep meaning to have a go at this, and with such inspiring mentors > at the ready, there's really no better time than now. > > -Sara Sounds like a good idea :) -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:

Re: [PHP-DEV] State of the named_params RFC

Hi! > I heard that the named_params RFC[1] was mostly done but needed a Was it? The RFC seems to be last edited about 3 years ago and I don't remember much discussion on it since. Given that it targeted 5.6, it's probably way out of date and also last time I remember it lacked consensus on the

Re: [PHP-DEV] RFC: operating system specific features

Hi! > I wanted first to know if php source code can welcome oses specific > features or should it remain as separated php modules ? If it's an extension, there's nothing wrong with OS-specific ones - though it would be in a good taste to clearly mark it as such in the documentation. The code

Re: [PHP-DEV] [PATCH] Make var_export() output "(object)array(..." instead of "stdClass::__set_state(..." for stdClass

Hi! > Additionally I feel that adding methods to stdClass will muddy the waters > -- for example, this means that extending stdClass is no longer entirely > unreasonable, as you might want to do it to reuse the __set_state() > implementation. Not something I want to see happening. I'm afraid

Re: [PHP-DEV] [Discussion] is_string(), string type and objects implementing __toString()

Hi! > This is not true at all: > > 1. is_dir Oh come on. I assumed I don't need to explain that the context was about is_* functions for types, not every function that starts with is_*. It doesn't even make sense to compare is_string to is_dir. -- Stas Malyshev smalys...@gmail.com -- PHP

Re: [PHP-DEV] [Discussion] is_string(), string type and objects implementing __toString()

Hi! > I submitted a GitHub PR* to allow objects implementing __toString() to > *optionally* pass is_string() validation. More verbose wording of my > motivation can be seen in the PR description, but here are the main > points: I don't think it's right approach. is_* functions check the current

Re: [PHP-DEV] Nullable types and strict type-hinting with default null value

Hi! > Scalar types declarations were introduced in PHP 7.0 but it was not > possible to pass null as a default value to function/method. It was > finally done by a small workaround described in documentation as "The > declaration can be made to accept NULL values if the default value of > the

Re: [PHP-DEV] [RFC][VOTE] Binary String Deprecation

Hi! > While that's an understandable argument, what happens if we flip it? Is > there any benefit to keeping it? Yes. Not having to change it :) Please note that the barrier for changing something, especially in a mature software product like PHP, especially in a core language, is way way higher

Re: [PHP-DEV] [RFC][VOTE] Binary String Deprecation

Hi! > I can't speak for others, but for me, it's simply because there's no > reason to do it (remove it), while there may/might be a reason to > keep it going forward. Keeping it comes at zero cost, and if we ever Same here. I just don't see what is improved by this removal. To me, it's just

Re: [PHP-DEV] Namespaces in Core

Hi! > New classes within 7.2 (e.g. \HashContext) to be moved without concern > for BC (e.g. \php\Hash\HashContext) > > Older classes (e.g. \RecursiveIteratorIterator) to be moved AND > ALIASED FOR BC (e.g. \php\SPL\Iterator\RecursiveIteratorIterator) Do we really need this? I mean, it's not

Re: [PHP-DEV] Namespaces in Core

Hi! > I'm strongly against use of the PHP namespace as a blanket namespace for > bundled PHP extensions. The PHP namespace should be used only for > functionality that is actually in some way related to PHP. For example, the > php-ast extension could reasonably be namespaced as php\ast, as it

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.2

Hi! > BUT, it would great to fix the inability of __toString to throw in 7.2 also. That might be a bit harder to do. __toString does not throw because it's used in many contexts inside the engine where you can't just drop what you're doing and start processing the exception - like in the middle

Re: [PHP-DEV] Class Constant Finalization

Hi! >> Given that we can now declare a class constant as public, protected, or >> private, can we also declare them final in 7.2? > > That doesn't make much sense to me. Constant belongs to a class. I don't > see much utility in "no class extending from this one can define > constant with the

Re: [PHP-DEV] Class Constant Finalization

Hi! > Given that we can now declare a class constant as public, protected, or > private, can we also declare them final in 7.2? That doesn't make much sense to me. Constant belongs to a class. I don't see much utility in "no class extending from this one can define constant with the same name".

Re: [PHP-DEV] Not autoloading functions

Hi! > Since the autoloading functions proposal is stalled, how about allowing for > import of static functions instead? > > use function Foo::bar; > > bar(); // calls Foo::bar() I'm not sure why it is good. This would certainly be confusing, if you call strlen and turns out it's

Re: [PHP-DEV] Typed properties problems

Hi! > Exactly. Scalars can change datatypes without warning. That's powerful, > but also migrane inducing when not used properly. Not really, scalars can't change datatypes. Variables can hold values of different datatypes, and certain operations can convert values between types. This is the

Re: [PHP-DEV] Typed properties problems

Hi! >> That's pretty messed-up right there. At least in the object cases there's >> an E_WARNING "Creating default object from empty value" - with the array >> case, nothing, it just converts your boolean into an array. Yikes. This works only on "empty" values, btw - null, false and "". And

Re: [PHP-DEV] Typed properties problems

Hi! > That's pretty messed-up right there. At least in the object cases there's > an E_WARNING "Creating default object from empty value" - with the array > case, nothing, it just converts your boolean into an array. Yikes. You told PHP you want an array, you get an array. -- Stas Malyshev

Re: [PHP-DEV] bugsnet cleanup

Hi! > Well, what is missing is a simple means to ping another developer – > currently the only way to do so is assigning the ticket to them, but > that's not always appropriate. True. Should not be hard to implement though I think. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP

Re: [PHP-DEV] bugsnet cleanup

Hi! > Nothing: it's just a forgotten corner of the web, like our Jira was. I'm sorry, I don't get this "forgotten corner" thing. What exactly is missing there - glitter? Celebrity endorsements? We have a fully functional tool, easy to use and available to anybody that needs it. We do not have to

Re: [PHP-DEV] bugsnet cleanup

Hi! > People can now cross-reference issues, discuss, get notifications, and > have some simplified/readable markup. All this, except for markup, is available on bugs.php.net. And I don't think markup is that important - I'm pretty sure one can discuss bugs in plain text. > For the 99% of

Re: [PHP-DEV] Improving mail() 5th parameter handling

Hi! > I'm planning to use extra_parameters array like > > $opts = [ > '-f' => 's...@example.com ', // Envelope sender > '-4' => null, // Force IPv4 > '-au' => 'u...@example.com ', // SMTP auth user > '-ap' => 'secret', // SMTP auth

Re: [PHP-DEV][RFC][DISCUSSION] - Immutable classes and properties

Hi! > Discussion is open for following rfc https://wiki.php.net/rfc/immutability The RFC says: > Safe for concurrency. I'm not sure - what concurrency are you talking about? > Value objects, DTO's etc. can be easily created. Value objects can be easily created right now if you follow generic

Re: [PHP-DEV] Improving mail() 5th parameter handling

Hi! > - Allow array additional_parameter and soft deprecate (document > deprecation) string one. > - Use key as "option name" and validate chars > - Use value as "option value" and validate some control chars then apply > escapeshellarg() Making array sounds good, but I'm not sure what is

Re: [PHP-DEV] bugsnet cleanup

Hi! > A lot of the time a feature request is just not enough; it requires at > least a good discussion, if not an RFC. True, but some people can not write an RFC, or not ready to do it, however they still can request and discuss features. > That there were feature requests open on bugsnet for

Re: [PHP-DEV] Exposing jsonSerialize's depth

Hi! > For short the thing is: "We have objects that do dynamic loading and > there might be recursions. We could use recursion depth to decide > when we want to do dynamic loading and when not. > This looks like a hack covering for deficient design. Having objects that look differently

[PHP-DEV] http://php.net/usage.php

Hi! With all this wonderful new year's work going on, should we also update (or remove, if we don't want to update it anymore) http://php.net/usage.php ? With data from 2013 it looks kind of pathetic :) -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing

Re: [PHP-DEV] bugsnet cleanup

Hi! > Some of you may have noticed that a few of us have put considerable effort > into cleanup of pull requests on github, these are now manageable and I'm > quite confident that we will be able to merge pull requests in a timely > manner, and stay on top of it. I would like to start with a big

Re: [PHP-DEV] bugsnet cleanup

Hi! > I'd even go as far as saying that any bug reported for PHP < 5.6 can be > marked as "Won't fix". The bugs targeting 5.6 need to be checked whether > they have a security implication and if not they should be also marked > as "Won't fix" Lots of people run 5.5 now. I'd say at least about

Re: [PHP-DEV] Fwd: Monotonic Time

Hi! > I think we can reuse parts of it to implement a function in core to access > a monotonic time, I don't think we need to merge the extension into core. What's wrong with just having an extension? -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing

Re: [PHP-DEV] [RFC] HashContext as Object

Hi! > I was trawling through Pull Requests and found #660 which I think is a > nice idea and deserves some attention. It involves minor BC however, > so I've updated the patch and presented it for your discussing > pleasure. > > https://wiki.php.net/rfc/hash-context.as-resource The RFC looks

Re: [PHP-DEV] Re: [RFC] Deprecations for PHP 7.2

Hi! >> https://wiki.php.net/rfc/deprecations_php_7_2 Reading through the list, I find several categories: Completely ok: (unset) - don't see any sane use case anyway gmp_random Can cause breakage but it's ok: $php_errormsg __autoload mbstring.func_overload parse_str() - people can use it

Re: [PHP-DEV] Use pthread in php extension

Hi! > Of course you can link your extension with any possible library. > Particularly with pthreads, when PHP is compiled non thread safe, you > need to be very careful using the PHP APIs. Many will be not thread > safe in that case. Best strategy were probably not using PHP APIs in > the thread

[PHP-DEV] unstable Travis CI builds

Hi! I've noticed that recently there is a real lot of random failures on Travis CI. E.g. this build: https://travis-ci.org/php/php-src/builds/179298649 two tests fail: ext/sysvsem/tests/nowait.phpt and sapi/cli/tests/php_cli_server_017.phpt Im different builds different random tests fail. Did we

[PHP-DEV] php.net mailing setup owner?

Hi! Is there somebody around who knows what happens with configuration of mailer in php.net domain? I get my mails sent to @php.net addresses bouncing for months now, I get this every time I try it: 550 5.7.1 Please change the topic, and retry Needless to say, it's useless to have @php.net

Re: [PHP-DEV] Re: [RFC] Parameter No Type Variance

Hi! > Anyone else interested in the usage of "mixed" as an explicit type > declaration? Please no. We already have "mixed" - every variable is "mixed". We don't need more cruft in the code that does not add anything that doesn't already exist. -- Stas Malyshev smalys...@gmail.com -- PHP

Re: [PHP-DEV] [RFC] Distrust SHA-1 Certificates

Hi! > You can read the full RFC in the wiki: > https://wiki.php.net/rfc/distrust-sha1-certificates I would propose making a constant for default value. This way if your code wants to use that option is a generic way, there is a value to fall back on, and you don't need to keep around a long

Re: [PHP-DEV] Encouraging maintaining the language spec

Hi! > If I edited the RFC template to mention having a language specification > patch, would anyone object? Great idea, than you for adding it! -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] ArrayIterator improvements

Hi! > Hello PHPeeps, I've updated the RFC! Have a look at it, please! (Sorry for > the engrish) Now the RFC says " if the given key is present in the array the method would successfully return null". While technically in PHP not returning value and returning NULL is the same thing, I'd just omit

Re: [PHP-DEV] [RFC] Abolish 50%+1 Votes

Hi! > Sorry, but yes. > > http://wiki.php.net/rfc/voting > >> There'd be a minimum of 2 weeks between when an RFC that touches the > language is brought up on this list and when it's voted on is required. > Other RFCs might use a smaller timeframe, but it should be at least a week. I must say

Re: [PHP-DEV] [VOTE] ArrayIterator improvements

Hi! > I'm not a internals programmer myself but I have consulted some and they > said proposed features are ok and implementation would be trivial, so I > thought it was ok to do this. Sorry for that. If proposed features are so trivial that they do not warrant any discussion, then there's no

Re: [PHP-DEV] [VOTE] ArrayIterator improvements

Hi! On 11/22/16 9:05 AM, Wes wrote: > Greetings PHPeople, > > I've just started the voting on the RFC at the URL... > > https://wiki.php.net/rfc/arrayiterator-improvements > > ...skipping the discussion period entirely as it's about small additions > and there's (hopefully) not much to discuss

Re: [PHP-DEV] function overloading

Hi! > a typical use case would be > > class EventHandler { > public function handle(ProductCreated $event) { > ... > } > public function handle(ProductNameChanged $event) { > ... > } > } > > vs what's currently being done: > > class EventHandler { > public

Re: [PHP-DEV] function overloading

Hi! On 11/15/16 8:13 AM, Dominic Grostate wrote: > I think this may have been discussed before, but I was largely dismissed > because no one though it would be possible to implement. > > However assuming it is possible, what is the general feeling towards > function overloading, as seen in C#

Re: [PHP-DEV] [VOTE] Debugging PDO Prepared Statement Emulation

Hi! On 11/16/16 3:06 PM, Adam Baratz wrote: > Hi, > > No, you're not misreading the subject line. I began working on the docs for > the previously accepted proposal and became uncomfortable with the > approach. I think it will be better to integrate this info into >

Re: [PHP-DEV] Countable Type Hint

Hi! > Nothing prevents it? As far as I'm aware there's no current way to type > hint Countable or array. No, there's not - as there's no way to make other complex type conditions as type. You still can check for it, or just use count(). > How would one add an interface that includes Countable

Re: [PHP-DEV] [RFC] Typed Properties

Hi! > Any plans to revive this RFC or is it officially dead? I really wish people won't use [Vote] subject in topics having nothing to do with RFC voting start/stop. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:

<    1   2   3   4   5   6   7   8   9   10   >