Re: [PHP-DEV] re2c version(s)

Hi! > re2c is not a problem for Windows either, it is bundled as part of the > PHP SDK. OK then, Windows is not a problem, that makes it better. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] re2c version(s)

Hi! > I would offer that this is what official releases and/or snaps.php.net is for. Do you mean releases would contain the generated files but the regular source won't? I am not sure then why - if we say our "official" source has generated files, why keep VCS out of sync with the source? Also,

Re: [PHP-DEV] re2c version(s)

Hi! > On Linux distros on common platforms (Intel/AMD) - sure. But what if you > need an uncommon platform, or one that does not run Linux? It's those > platforms where you'd have to build PHP from source (after all, PHP is > also widely available as a package on Linux distros anyway) and adding

Re: [PHP-DEV] re2c version(s)

Hi! > the timelib files *must* be generated with 0.15.3: > https://github.com/mongodb/mongo/blob/master/src/third_party/scripts/timelib_get_sources.sh#L10-L11 That comment says 0.16 was problematic. Is it still true for 1.0.*? Was it reported to re2c? -- Stas Malyshev smalys...@gmail.com --

Re: [PHP-DEV] re2c version(s)

Hi! > re2c is widely available on Linux distros nowadays (probably On Linux distros on common platforms (Intel/AMD) - sure. But what if you need an uncommon platform, or one that does not run Linux? It's those platforms where you'd have to build PHP from source (after all, PHP is also widely

[PHP-DEV] Re: Maintainership dates

Hi! > In my opinion, these should be treated basically like unmaintained > extensions, i.e. issue a call for maintainership. It seems to be > appropriate to explicitly CC the listed maintainers, though. > > However, I would prefer to issue the calls for maintainership one by > one, or more

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

Hi! > - As I said earlier, this patch has already been tested against some > extremely tricky scenarios, so from a userland perspective it is safe for > inclusion. If you don't have confidence in something related to it, please > write a test case and help out. It sounds like you are talking

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

Hi! > Ah, thanks, Nikita! Considering this, I'm not against delaying beta1 > for two weeks and having an alpha4, provided that we do not allow any > new (i.e. not yet under discussion) RFC to target 7.3. > > Stas, what do you think? Sorry for late answer, I've been behind my emails due to

Re: [PHP-DEV] [RFC] abolish narrow margins

Hi! > Things which don't effect the language, but are more of a question of > preference - e.g., the decision to name phpng as PHP 6 vs PHP 7 - or for > that matter, deciding about a different release cadence. It's one thing to That's one of the places where 50% or plurality vote would be

Re: [PHP-DEV] [RFC] abolish narrow margins

Hi! > See > and particularly . Ah yes, thanks, I thought I remembered something like that. It's a bit old but still good. Looks like the number of RFCs that would suffer from move to 2/3 is very low, thus I think it's a good

Re: [PHP-DEV] [RFC] abolish narrow margins

Hi! > We discussed it a year ago, and discussion died down to nothing (possibly > because it was sidetracked); If there are no objections I'll bring it to > vote in the coming days ... I tend to agree with the sentiment, but not 100%. I think there are two kinds of changes - one kind is more

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

Hi! > the wall. By deciding not to include this in PHP 7.3, we are essentially > making an implicit decision that PHP 7.4 is going to be a relatively > ordinary feature release rather than a deprecation-only one. (Which is fine > by me really, I don't like the idea of a release that's all stick

Re: [PHP-DEV] On not rushing things at the last minute

Hi! > I'm disappointed by the last minute kitchen-sink dump of RFCs being > raised, rushed through discussion, and voted on with minimal periods. > While I'm all for delivering useful features to end users, I don't > want us to get in the habit of seeing months of quiet followed by > weeks of

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

Hi! > After looking into this, I think that FILTER_SANITIZE_MAGIC_QUOTES may be a > legitimate filter, which just has a bad name. Next to other filters that > perform htmlspecialchars and urlencode, it makes sense that there is also a > filter that performs addslashes. Maybe we should just rename

Re: [PHP-DEV] [RFC] Deprecate and remove continue targeting switch

Hi! > Should I just go ahead and implement the warning (with no intent of > future removal), or do we want to still go through the RFC here? I think it's ok to just add the warning, unless somebody objects. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development

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

Hi! > So basically the practical BC impact of making them reserved keywords > would only be a) cannot be used via constant() anymore and b) can't > declare global functions with these names. I think b) is completely fine (I don't think anybody needs a function named "true" - would be very

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

Hi! >> Procedural question: Would you prefer that the vote for this (and the other >> two deprecation RFCs) is one week (the minimum voting period), or that the >> vote is two weeks but the deprecations land for beta 2 rather than beta 1? > > Hmm, it's probably best to ship the deprecations (if

Re: [PHP-DEV] [RFC] User-defined object comparison

Hi! > In other words, $a == $b must not work if $a->__equals and $b->__equals are > two different functions > > So effectively it means we only call __equals if both sides are instances > of the same class? We can just define that == calls __equals on the left. That's, for example, what Python

Re: [PHP-DEV] Excess arguments for internal functions

Hi! > IMO, we should go the other way. Deprecate excess args in userspace > functions (making them an error in 8.0). We've had formal variadics > in userspace for a long time (5.5 IIRC), this is a solvable problem. I think it's premature. We do have variadics, since 5.6

Re: [PHP-DEV] Equality and relative ordering of objects

Hi! > I think if you want to push the RFC forward, a really quite strong > case needs to be made for why having it be a language level feature is > so much better (or even at all better) than having it be implemented > in userland. I tend to agree here. There are not that many cases where < and

[PHP-DEV] Maintainership dates

Hi! Following up the proposal from Sara, I've made a patch to add dates to maintainership status in EXTENSIONS: https://github.com/php/php-src/pull/3357 I didn't touch SAPIs because it's not clear what to do with them (to me). Please check it out and comment. We have a bunch of extensions where

Re: [PHP-DEV] [RFC] Mixed type

Hi! > I would enjoy a 'mixed' typehint for exactly that reason; i.e., that I don't > have to put it in a docblock. I think it is exactly the opposite of what should be happening in the language - putting things in the code which belong in the documentation, so you don't have to write

Re: [PHP-DEV] [RFC] Mixed type

Hi! > Together with Michael Moravec, we’d like to announce that we are pretending > to open the Mixed Type RFC (https://wiki.php.net/rfc/mixed-typehint) next > Monday (02/07) and we’d like to ask you to take a look into the PR on > GitHub (https://github.com/php/php-src/pull/2603) and let us know

Re: [PHP-DEV] [RFC] [VOTE] Cleaning up unmaintained extensions Yasuo Ohgaki

Hi! > Readline is the only extension in your list that I would be sad about > losing. I use it every day, I guess a lot of devs do. It's not "losing", per se, as the code doesn't get erased, it just moved to PECL. All distros can build it from there just as they do now. Then again, if it's

Re: [PHP-DEV] [RFC] Deprecate and remove continue targeting switch

Hi! > In the proposal, the code is valid in all versions of PHP up to and > including 7.3, *and represents the same algorithm in all versions*. The > only difference would be the side-effect of issuing an additional > deprecation notice; that's not "a different meaning". In PHP 8, under >

[PHP-DEV] Re: [RFC] [VOTE] Cleaning up unmaintained extensions

Hi! > Seems the vote should have been closed already. :) Indeed! Thank you for the reminder, and sorry about me not putting reminder on my calendar to send the email about it. So here it goes: The vote result is 19 for and 4 against, which is 82% approving. This means this RFC has been

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

Hi! > - The (real) type-cast and its function, is_real(). There doesn't > seem to be any support for reals in settype() anyway (side note: in > the implementation of settype() it claims "double" is deprecated) > - Function variants that already exists as constants, php_sapi_name() >> PHP_SAPI,

Re: [PHP-DEV] [RFC] Deprecate and remove continue targeting switch

Hi! > Do you mean that this code would be valid in both PHP 7 and PHP 8, but > mean different things? > > while($outer) { >     while($inner) { >         switch($foo) { >             case 1: >                 continue 2; >         } >     } > } > I think this would be unacceptable, because WTF

Re: [PHP-DEV] [RFC] Deprecate and remove continue targeting switch

Hi! > This leaves us in a position where "continue" means different things in > PHP and in other syntactically similar languages, causing confusing for > programmers familiar with them. This is solved by simply prohibiting the > case that is ambiguous. This is not a loss for PHP developers (who

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

Hi! > There are multiple bug reports regarding strip_tags()'s broken behavior > on (slightly) malformed HTML, e.g. , > and , which > renders the function unusable on arbitrary user supplied input. I see a very

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

Hi! > This RFC collects a number of deprecations for PHP 7.3 which I consider to > be too minor to warrant a separate proposal. However, each deprecation will > still be voted separately. > > https://wiki.php.net/rfc/deprecations_php_7_3 > Undocumented mbstring function aliases Not sure what

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

Hi! > https://wiki.php.net/rfc/case_insensitive_constant_deprecation > > This was already discussed some time ago on the list, though that > discussion degenerated into unfortunate directions. I'd very much > appreciate if we could keep discussions on making PHP fully case-sensitive > or fully

Re: [PHP-DEV] [RFC] Deprecate and remove continue targeting switch

Hi! On 6/24/18 9:16 AM, Nikita Popov wrote: > Hi internals, > > Another small deprecation for your consideration... > > https://wiki.php.net/rfc/continue_on_switch_deprecation Not sure I understand - what this is improving? Yes, continue being the same as break is slightly surprising, but it

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

Hi! > Finally, while this RFC currently targets PHP 7.3, this is a large and > complex proposal and we may not be able to meet the deadline, in which case > this feature will go into the next PHP version. I haven't read the RFC yet, so I just want to address this point. I think unless the RFC is

Re: [PHP-DEV] Cleaning up unmaintained extensions - interbase

Hi! > The last time I managed to patch php was over 15 years ago, I have not > been able to get a handle on the new structure used by PHP7 in part > because I've not had time to do any C coding since. I'm still working on > moving PHP5.2 code to work on PHP7 while keeping the stack working on >

Re: [PHP-DEV] [RFC] [VOTE] Cleaning up unmaintained extensions

Hi! > What Bug! > It's passing all the test that I run on it perfectly stably otherwise I > would not even bother with PHP7. But the problem supporting ANY driver > is the exotic nature of PHP is just as difficult as the tools it needs > to interface with to make a fully functional stack ... I

Re: [PHP-DEV] [RFC] [VOTE] Cleaning up unmaintained extensions

Hi! > There are two extensions that I'm aware of where we have strong > technical grounds to remove them, that's wddx (for reasons of security > and questionable utility) and interbase (has a major bug since the PHP 7 > migration and there is nobody with knowledge of this exotic DB driver to >

Re: [PHP-DEV] [RFC] [VOTE] Cleaning up unmaintained extensions

Hi! > Hi! > > I would like to open the vote for the RFC about cleaning up the > unmaintained extensions: > > https://wiki.php.net/rfc/umaintained_extensions > > > The vote ends 2018-06-26 23:59 PDT. > > > Just to be

Re: [PHP-DEV] xmlrpc extension maintainership?

Hi! > is there a list available with unmaintained extensions which are still > inside the core? Current list is here: https://wiki.php.net/todo/extensions This may change periodically. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To

[PHP-DEV] xmlrpc extension maintainership?

Hi! About 2 years ago, in https://externals.io/message/94540#94546, you expressed interest in maintaining XML-RPC extension. I haven't seen any activity from you since then. Are you still interested? If so, it might be a good idea to look through XMLRPC bugs:

[PHP-DEV] [RFC] [VOTE] Cleaning up unmaintained extensions

Hi! I would like to open the vote for the RFC about cleaning up the unmaintained extensions: https://wiki.php.net/rfc/umaintained_extensions The vote ends 2018-06-26 23:59 PDT. I have added some discussion about active maintainers and abandonment procedures, this can be refined further later.

Re: [PHP-DEV] Strict switch statements

Hi! > Would both be more apparent as to its meaning and leave the door open > for other uses. Though at that point, tbqh, I think `switch ($a) use > (===) {...}` gives better visual isolation. I don't think we should reuse the use() thing for third purpose when we're already using it for two. I

Re: [PHP-DEV] Strict switch statements

Hi! > switch ($a) { > case FOO: > // Works exactly as current behavior. > break; > case == FOO: > // Nearly identical, though not using the ZEND_CASE optimization. > // Can probably make this equivalent to `case FOO`, but it felt > like an interesting direction. >

Re: [PHP-DEV] Re: [RFC] orphan extensions cleanup

Hi! > That said, in my opinion it is too late for 7.3 to move a bundled > extension to PECL, except perhaps for unresolved or even unresolvable > security reasons. ext/wddx comes to mind, and maybe there are others. I'd be happy to move wddx if nobody steps up to maintain it. It has tons of

Re: [PHP-DEV] Re: [RFC] orphan extensions cleanup

Hi! >    I'm afraid this might be misused.  It's too easy to update the year >    number, without actually doing *any* real maintenance work (“I'll come >    back to that later” …).  Some automated process would be nice, but >    manually checking the bug tracker for maintenance work

Re: [PHP-DEV] Re: [RFC] orphan extensions cleanup

Hi! > Per issue #1, I'd suggest an OWNERS file per ext/*/ dir with names and > year ranges. Continued ownership demarked by explicitly incrementing > the end year BY THE MAINTAINER. An extension is considered abandoned > if the end year is not updated by the following January. Example: Makes

[PHP-DEV] Re: [RFC] orphan extensions cleanup

Hi! > I think it is *very* important to finally tackle this topic. Since > it is rather late for actually moving several extensions to PECL for > PHP 7.3, and since this would be an ongoing process anyway, I suggest > to I'm not sure it's too late for 7.3. If we see that the extension is

[PHP-DEV] PHP 7.3.0 alpha 1

Hi all! PHP team is glad to announce the release of the first PHP 7.3.0 pre-release version, PHP 7.3.0 Alpha 1. This starts the PHP 7.3 release cycle, the rough outline of which is at: https://wiki.php.net/todo/php73 The source code can be downloaded from: https://downloads.php.net/~stas/

Re: [PHP-DEV] PHP 7.3 timetable

Hi! > I've pushed the fingerprint of my GPG key to web-php[1], and also made > it available on pgp.mit.edu[2]. As I understand it, this should be > sufficient to sign it. Otherwise, please tell me what to do. Should be enough to start signing packages, I assume. -- Stas Malyshev

[PHP-DEV] Re: PHP 7.3 timetable

Hi! > Due to some pending preliminary work, I won't be able to release > 7.3.0alpha1 on Thursday. Unless Stas is willing to tackle the first > alpha, I suggest to postpone the tentative timetable[1] by a week. I > don't think that would be a problem, since 7.0 - 7.2 had their first > alphas

Re: [PHP-DEV] Re: RM karma

Hi! Don't know about the downloads, unfortunately, but I think you should have the full commit karma, at least from my reading of the karma file. I can definitely put the binaries into my directory on downloads, at least for now. Can't help much with the lists though (except for sending the

Re: [PHP-DEV] Re: PHP 7.3 Release Manager Selection

Hi! > I want to encourage anyone who is "on the fence" or worried they won't > be able to pull it off to just go for it. We have a large group of > active, experienced RMs, a decent supply of tooling, a surprising > amount of documentation, and if circumstances change and you just > can't do the

Re: [PHP-DEV] PHP FFI extenesion

Hi! > I've spent some time thinking about simple FFI for PHP, and finally, borrowed > most ideas from LuaJIT. > > This is an initial PoC. It was tested on Linux only. > > > https://github.com/dstogov/php-ffi > > > I would appreciate review, comments and ideas about missing features and >

Re: [PHP-DEV] Re: [RFC] Base Conversion Clowniness

Hi! > Technically, the internal API as it stands *can* return FAILURE > already, though I can see your argument that a caller might assume > that it'll never fail so long as they pass a string with a valid base. > I don't think I agree with your point, as it's reasonable to expect an > API caller

Re: [PHP-DEV] Re: [RFC] Base Conversion Clowniness

Hi! >> https://wiki.php.net/rfc/base-convert > > Is there any chance to revive this RFC? There are at least three > tickets in the bug tracker regarding the sloppy behavior of base_convert(): I think if we want to take this RFC forward it should be reduced to either proposing one action,

Re: [PHP-DEV] run-tests.php exit code

Hi! > If behavior wasn't changed unless ENV var or CLI option was specified, > then I think it can go into 7.1  (run-test.php isn't production code > part of a build, etc...). The point is to change behavior - namely, make run-tests return proper exit code even if no variables are set. True,

[PHP-DEV] run-tests.php exit code

Hi! When running tests with run-tests.php, if the tests fail, the script will exit with non-zero exit code, but only if REPORT_EXIT_STATUS is set. This was the case since 2002 when this capability has been introduced. I think it would be nice if we reversed the default and made the script use

Re: [PHP-DEV] FPM maintainership?

Hi! >> Great! There are also a number of issues in the bug db for FPM that >> could use a review, and I am not sure what to do about >> https://bugs.php.net/bug.php?id=75605 specifically... > > You do realize that this bug is marked private, thus nobody can say > anything about it... Not nobody

[PHP-DEV] Setting up CNA for PHP CVEs

Hi! I've been complaining in the past about the way PHP CVE are handled - they are sometimes issued with no coordination with anybody from PHP developers, sometimes contain misleading and outright wrong information and sometimes disregard our guidelines for security issues

Re: [PHP-DEV] FPM maintainership?

Hi! > I already work on it and not sure if there is any other dev actively > works on it so I would be happy to step up as a maintainer whatever it > means :) I want however keep working on my plan so the current priority > is to sort the logging out because it is causing many issues. Great!

Re: [PHP-DEV] FPM maintainership?

Hi! > I already work on it and not sure if there is any other dev actively > works on it so I would be happy to step up as a maintainer whatever it > means :) I want however keep working on my plan so the current priority > is to sort the logging out because it is causing many issues. Great!

[PHP-DEV] FPM maintainership?

Hi! I'd like to raise the question of FPM SAPI maintainership. Is it still maintained? If so, by whom? Jerome Loyet is listed as a maintainer, but his last commit has been in 2012, as far as I can see, and I see no activity from him on the bug tracker for the last couple of years (maybe more).

Re: [PHP-DEV][RFC][DISCUSSION] Deprecate the backtick operator

Hi! > Actually, for me the only valid argument to deprecate the backtick > operator is "because it is a shady way to execute a rare and dangerous > operation". I, personally, would make that the main reason for the > deprecation proposal, and would move the other arguments to the "future >

Re: [PHP-DEV][RFC][DISCUSSION] Deprecate the backtick operator

Hi! On 2/12/18 10:26 AM, Wes wrote: > There is not much to say. You either agree with it or you don't. And I That's not how consensus discussion process in RFCs should work. It's not just throwing your opinion over the fence, because the response would be

Re: [PHP-DEV] Proposal to run all tests with and without strict_types enabled

Hi! > My proposal is to run all tests with and without strict_types, skipping if > necessary, and increasing the code coverage. Depending of you overral > reception I'll create an RFC for it. I am not sure what would be the advantage of this. Beyond testing strict_types functionality itself

Re: [PHP-DEV][RFC][DISCUSSION] Deprecate the backtick operator

Hi! > It's absolutely impossible to treat notices as errors in PHP, so I > assume everybody thinks the same. If someone converts notices to > ErrorExceptions or something, it's their fault. > A notice in tests is exactly what a deprecation is supposed to do, force > people to update their code.

Re: [PHP-DEV][RFC][DISCUSSION] Deprecate the backtick operator

Hi! > Hello PHPeople, I present to you... the shortest RFC ever. > > https://wiki.php.net/rfc/deprecate-backtick-operator > > Let me know what you think! I think we need a bit more explanation that that. Why would we want to use backticks for Unicode strings? Why we need to deprecate existing

Re: [PHP-DEV] Replaced the bundled libgd with upstream (aka. system) libgd

Hi! > During the discussion of PR 3080[1] the idea to replace our bundled > libgd with an (unmodified) upstream libgd[2] has come up again. It > seems this issue deserves its own discussion, and probably an RFC. I think this is a good idea. In general, as open source ecosystem matures (and more

Re: [PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope

Hi! > It's an ironic coincidence that you use strlen() as an example. > Because it and substr() are possibly the most likely to be overriden, > where we need code to be byte-safe in spite of mbstring.func_overload. Also happens rather rarely, in my impression, since you'd have to a) run

Re: [PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope

Hi! > We're talking about a deprecation, not removal of a feature. There's no point of deprecating if the goal isn't to remove. > First of all, it doesn't remove the feature, which means that everything > keeps working as-is, and second, we already have a way to configure error > reporting for

Re: [PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope

Hi! >>> To get the same benefits (jit and such) wouldn't it be better to introduce >>> a "use function root;" or similar statement or a declare() to specify this >>> file imports all root functions? >> >> We already have this right now, […] > > Do we? AFAIK, it is not possible to import *all*

Re: [PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope

Hi! >> None of these options is particularly appealing, and this will all be for a >> hypothetical future improvement to the language. >> > > Would proposing a function autoloading RFC together with this improve the > situation? No. Function autoloading addresses the needs of tiny part of the

Re: [PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope

Hi! > I also think it's a stretch to call people affected by this change "our > worst users". I don't know if any common coding standards cover leading I think you can call them just "our users". I haven't seen any code that does \strlen or \substr all over the code base. In my opinion,

Re: [PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope

Hi! > That said, I'm not sure that function autoloading will be that big of a > carrot > for the major projects at this point. Wordpress is going to ignore anything If they pay for that is to edit every single file that uses global functions (which is all of them) or suffer a hailstorm of

Re: [PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope

Hi! > Yes we do have root namespace lookup, but its not automatic, it is only > as a fallback. This RFC is about removing the intermediate namespace'd > check, hence requiring \strlen. It is automatic, in the meaning you don't have to do anything to get it. Realistically, how often do you

Re: [PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope

Hi! > To get the same benefits (jit and such) wouldn't it be better to introduce > a "use function root;" or similar statement or a declare() to specify this > file imports all root functions? We already have this right now, and realistically speaking, who wouldn't do that in their code instead

Re: [PHP-DEV] Potential adoption of run-tests.php replacement

Hi! > There is a project I've created a long time ago and still maintaining > (https://github.com/nazar-pc/phpt-tests-runner) that should be able to run > most of the tests without changes already with colored output and the whole > thing is a fraction of run-tests.php's size. Some notes: -

Re: [PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope

Hi! > I hope you like it. Let me know what you think. > > https://wiki.php.net/rfc/fallback-to-root-scope-deprecation I do not see how this makes sense. This RFC claims there's no BC breakage, while it deprecates one of the most widely used functions of the language (using unqualified global

Re: [PHP-DEV] Potential adoption of run-tests.php replacement

Hi! On 1/31/18 2:50 AM, Nazar Mokrynskyi wrote: > The idea is to make filenames more descriptive and sufficient for > displaying in test results. Descriptive - sure, that'd be great, why not. Sufficient - won't happen. Filenames are not meant to describe complex things, are not suitable for it

Re: [PHP-DEV] Potential adoption of run-tests.php replacement

Hi! > For instance, it is painful to work with tests in PHP source tree when they > are called 001.phpt, 002.phpt and so on - you need to open each file and read > it to see what it intends to test. My tool uses file names instead, which > makes browsing source tree with tests more productive

Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax

Hi! > I want to see strict typing as an option, not a requirement. You seem to be under impression that this somehow makes things easier. It does not. To explain: let's say you design a strictly typed language, like Java. The compiler knows which variable is of which type at every point, and if

Re: [PHP-DEV] null coalesce addition assignment operator ??+=

Hi! > I propose even more such operators: > null coalesce addition assignment ??+= (for strings and numbers) > null coalesce subtraction assignment ??-= > null coalesce increment ??++ > null coalesce decrement ??-- > null coalesce multiplication assingment ??*= I think this is taking it too far.

Re: [PHP-DEV] Mailing list moderation

Hi! > You may not like what I have to say, but that is no reason to ban me > from saying it. I believe in democracy and free speech, and by banning > or suspending me you are effectively banning the right to free speech. This has nothing to do with free speech. You are welcome to exercise your

Re: [PHP-DEV] RE: High resolution timer function

Hi! > If there are no further comments or objection, I would like to merge this > patch anytime soon and see to add a couple of helper functions for > diff/compare. No objection to the idea but please see my comments on https://github.com/php/php-src/pull/2976. -- Stas Malyshev

Re: [PHP-DEV] [RFC] Mixed Typehint

Hi! > Why document code? It contributes nothing to the behavior of the code, > well, unless you parse it as annotations. I am not sure I understand - are you arguing for supporting "mixed" in *documentation*? Then it's already supported and there's no need for any RFC. But if you're arguing for

Re: [PHP-DEV] [RFC] Mixed Typehint

Hi! > I'd like to propose and discuss Mixed Typehint RFC for PHP 7.3: > https://wiki.php.net/rfc/mixed-typehint > > The purpose of this RFC is to introduce "mixed" typehint on language level > to be used > as a valid typehint. PHP currently forces users to not use any type in case > the > type

Re: [PHP-DEV] [RFC] Reproducible Builds Support

Hi! >> I think the best solution here would be to have another variable to >> override this. > > The issue with this approach would be that every distribution has to set > this variable. I know it's the same with SOURCE_DATE_EPOCH, but that is > well established. All distros that want

Re: [PHP-DEV] [RFC] Namespace-scoped declares, again

Hi! > There is no dependence on loading order. The implementation is careful > to ensure that the used declare state is consistent. It's not possible > to call namespace_declare() twice on the same namespace. It's not > possible to first load some files from a namespace, do the >

Re: [PHP-DEV] [RFC] Explicit call-site send-by-ref syntax

Hi! > The issue, as you well know, is that references disable copy-on-write. Thus > assume you have code like this: > > function with_ref(&$a) { >count ($a); > } > > function no_ref($a) { > count($a); > } > > The count in with_ref() will copy the array, while no_ref() can use copy on >

Re: [PHP-DEV] [RFC] Namespace-scoped declares, again

Hi! > The idea is to allow specifying declare directives for a whole library or > project using: > > namespace_declare('Vendor\Lib', ['strict_types' => 1]); I am not sure I like this. Namespace is a prefix to a class name. Anybody can declare a class with any name, and the side-effect that

Re: [PHP-DEV] [RFC] Reproducible Builds Support

Hi! > Once issue is the PHP_BUILD_DATE, which makes the build > non-reproducible. I've made a PR which uses SOURCE_DATE_EPOCH which is > set in the reprodiculbe build env. This should keep the current > functionality intact, while adding support for reproducible builds. [2] > [3]

Re: [PHP-DEV] [RFC] Explicit call-site send-by-ref syntax

Hi! > I would rather discourage usage of references. Since PHP 7 the cost of > breaking cow isn't as expensive anymore, but receiving values by value > and returning by value is more idiomatic imo. Using objects can be more > efficient. Objects are kind of overkill when you just need a

Re: [PHP-DEV] instanceof survives non-object variables, but crashes on non-object constants.

Hi! > t think this behavior is inconsistent, and we should consider changing it. > > There are two options, but only one is BC. > > - Let 1 instanceof \stdClass return false, instead of crashing. -> seems BC > - Let $x instanceof \stdClass crash, if $x is not an object. -> BC break. Neither of

Re: [PHP-DEV] [RFC] Explicit call-site send-by-ref syntax

Hi! > I'd like propose optional support for explicitly marking by-reference > argument passing at the call-site, in addition to the declaration-site: > > https://wiki.php.net/rfc/explicit_send_by_ref > > In short, while currently we have > > function byRef(&$ref) {...} >

Re: [PHP-DEV] Public Tags of Releases

Hi! > If there's a mistake that needs to be fixed and that's detected within > these two days, a re-tag needs to happen. If the old tag is deleted and a > new modified tag is published, all cloned Git repositories that already > received the old tag will keep the old tag and never receive the new

Re: [PHP-DEV] Constants and Access Modifiers

Hi! > Yes, Dart has a different understanding of const, which is exactly why I > posted it for you guys. In the hope that it helps to get more different > views on the topic. Currently you are too concentrated on how it is > implemented in PHP at this time, and argue that it is impossible to >

Re: [PHP-DEV] Constants and Access Modifiers

Hi! > An abstract constant is a constant that requires its value to be defined > later, like an abstract method that requires its implementation to be > defined later. It's not a constant then, and should be a method. > > The thing is that I want something that CANNOT CHANGE. I want to require

Re: [PHP-DEV] Proposal: Rename image functions

Hi! > Step 1: > I create a patch with the new aliases. I don't see much wrong with old names - nobody remembers those names anyway, and once you use IDE or - for people that still type PHP code by banging two rocks together, like I sometimes do, the manual - it doesn't matter whether there is

Re: [PHP-DEV] Constants and Access Modifiers

Hi! > My wording was maybe a bit wrong here, and I was biased by the fact that > I would like to see abstract constants. The fact that not everything can What is "abstract constant"? If you need something that can change, just use a method. Constant is meant to be a nice way to write something

Re: [PHP-DEV] [RFC][VOTE] Flexible Heredoc and Nowdoc Syntaxes (voting restarted)

Hi! > As per feedback here, I have updated the first voting question for > additional clarification. This has restarted the vote for the first > question only. The second vote will continue as normal, and both will > still end on the same date (November 15th). Thank you! -- Stas Malyshev

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