Re: [PHP-DEV] [RFC] Warning for implicit float to int conversions

4, 2021, at 12:06 PM, David Gebler wrote: > > If this were to be done, my gut feeling is a notice would be preferable > to > > a warning, particularly as there must be many scripts which would > suddenly > > start churning out warnings for this proposed change which might/pro

Re: [PHP-DEV] Interaction between finally blocks and exit()

Interesting. I'm not sure there's a "correct" answer here, but FWIW on balance my feeling is the expectation that exit() will immediately terminate a script (registered shutdown functions and destructors aside) should take precedence over the expectation that finally blocks will always execute, jus

Re: [PHP-DEV] [RFC] Warning for implicit float to int conversions

> Floats (doubles) can accurately represent all integers up to 2⁵³, so there > is no inaccuracy in this range; the result from round() or floor() could > therefore be safely passed to (int) even if the cast operator checked for a > 0 fractional part, which is what I'm advocating for. Generating a

Re: [PHP-DEV] [RFC] Warning for implicit float to int conversions

This is all a bit moot anyway, the RFC proposal is for warnings or notices on implicit casts only. I'm not a voting member for RFCs so my opinion is mere food for thought, nonetheless my two cents is that: a) The proposal relies on a premise that an implicit cast of (non-zero fractional) float to

Re: [PHP-DEV] [RFC] fsync function

ns or clarifications? To summarise: - Adds fsync() and fdatasync() for plain file streams on Unix systems. - Adds fsync() on Windows with fdatasync() as an alias. Thank you. RFC ref: https://wiki.php.net/rfc/fsync_function PR ref: https://github.com/php/php-src/pull/6650 -Dave On Wed, Feb 3, 2

[PHP-DEV] Inline conditional that returns null if falsy

my suggestion we have: return $languageFirst instanceof LanguageExperience => $languageFirst->title; The => is just a suggestion, other options using existing keywords is: return expr() then output(); return expr(): output(); I do not know if other languages support something like that. Thanks! Atenciosamente, David Rodrigues

Re: [PHP-DEV] Inline conditional that returns null if falsy

Em sáb., 13 de fev. de 2021 às 00:11, Marco Pivetta escreveu: > Hey David, > > Even upfront, this looks like a quite bad idea: either you have an empty > collection, or you have a collection with elements in it, but `null` is a > very different concept that isn't homogeneou

[PHP-DEV] preg_replace(string, null) is allowed?

! Atenciosamente, David Rodrigues

Re: [PHP-DEV] preg_replace(string, null) is allowed?

Thanks! There is a reason why it is not supported anymore? There is a difference in output or performance, maybe? Atenciosamente, David Rodrigues Em qua., 17 de fev. de 2021 às 17:37, Nikita Popov escreveu: > On Wed, Feb 17, 2021 at 9:28 PM David Rodrigues > wrote: > >> He

[PHP-DEV] [VOTE] fsync function

. - Adds function fsync() on Windows with fdatasync() available as an alias PR ref https://github.com/php/php-src/pull/6650 Regards, David Gebler

Re: [PHP-DEV] Inline conditional that returns null if falsy

Em qua., 24 de fev. de 2021 às 12:29, Michael Morris escreveu: > Javascript has this now though support isn't widespread. > > > https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Optional_chaining > > The most similar way to do it in PHP would be ?-> > Optional chaining

Re: [PHP-DEV] [VOTE] fsync function

Voting is now open for 2 weeks on https://wiki.php.net/rfc/fsync_function Regards, David Gebler On Tue, Feb 23, 2021 at 5:15 PM David Gebler wrote: > Hi internals, > As there appear to be no objections or concerns, I intend to open voting > on https://wiki.php.net/rfc/fsync_function

Re: [PHP-DEV] [VOTE] fsync function

Thanks Marco, objection understood. I think Nikita's already said what I would say, from my view I can only reiterate I felt it was more appropriate to keep the behaviour consistent with how similar stream ops work. Regards David Gebler On Thu, 25 Feb 2021, 13:38 Marco Pivetta, wrote:

Re: [PHP-DEV] [RFC] class_name:namespace

ches),$matches); array(3) { [0] => string(23) "My\Namespace\Name\Class" [1] => string(17) "My\Namespace\Name" [2] => string(5) "Class" } Regards David Gebler On Thu, Feb 25, 2021 at 9:40 PM Manuel Canga wrote: > En jue, 25 feb

Re: [PHP-DEV] PDO integer changes in 8.1 will stop many websites I support

Hi Matthew, 1. PHP 8 has not introduced a change to PDO_MYSQL in respect of how values are fetched. What makes the difference as to whether you get MySQL INT values fetched as strings or integers is whether you are running PHP with the mysqlnd https://dev.mysql.com/downloads/connector/php-mysqlnd/

Re: [PHP-DEV] PDO integer changes in 8.1 will stop many websites I support

Apologies, in respect of point 1 in my reply, I misread your original message and didn't realise you were referring to the upcoming 8.1 change, thought you were referring to the current 8.0.1 release. This change AFAIK only affects emulated prepares and is an improvement, as previously you needed

Re: [PHP-DEV] [VOTE] fsync function

Thank you all for voting, which is now closed. This RFC has been accepted on the final tally. Regards David Gebler On Thu, Feb 25, 2021 at 2:13 PM David Gebler wrote: > Thanks Marco, objection understood. I think Nikita's already said what I > would say, from my view I can only

[PHP-DEV] Built-in decorator attribute?

With the introduction of attributes in PHP 8, this new behaviour is still quite sparsely documented. Some of the articles I've seen out there, though, liken PHP's attributes to similar constructs in other languages including decorators in Python. Attributes are not the same thing as (Python's conc

[PHP-DEV] Re: Built-in decorator attribute?

Oops, didn't tag the subject. On Sat, Mar 13, 2021 at 4:51 PM David Gebler wrote: > With the introduction of attributes in PHP 8, this new behaviour is still > quite sparsely documented. Some of the articles I've seen out there, > though, liken PHP's attributes to sim

Re: [PHP-DEV] Built-in decorator attribute?

Decorators are a way of bringing aspect oriented programming into PHP core, yes, among other uses. Go AOP is a fairly bulky framework which could be easily replaced by a Decorator attribute for the purposes of cross-cutting changes to function behaviour. Regards, David On Sat, Mar 13, 2021 at

Re: [PHP-DEV] Built-in decorator attribute?

efore hook and that might be sufficient control in practice. Regards, David On Sun, Mar 14, 2021 at 11:52 AM Benjamin Eberlei wrote: > > > On Sat, Mar 13, 2021 at 5:51 PM David Gebler > wrote: > >> With the introduction of attributes in PHP 8, this new behaviour is sti

Re: [PHP-DEV] Built-in decorator attribute?

nd powerful enough feature that it deserves more attention and forethought before I try to cobble something together as a Frankenstein monster. I'm starting to familiarize myself with the attributes implementation in the meantime to try and build up an idea of how I might build this. Regard

Re: [PHP-DEV] PDO::PARAM_INT and pgsql driver

might be a reason Postgres is implemented this way on PDO, I don't know, I'm not a Postgres guy. But the funny thing is it works exactly as expected when emulation is switched ON: $pdb->setAttribute(PDO::ATTR_EMULATE_PREPARES,true); $st = $pdb->prepare('SELECT baz(?)'); $st-&g

Re: [PHP-DEV] Built-in decorator attribute?

): # do some stuff is equivalent to foo = timer(foo) and @timer @somethingElse def foo(a, b, c): # do some stuff is equivalent to foo = timer(somethingElse(foo)) Regards, David On Mon, Mar 15, 2021 at 1:46 AM Peter Stalman wrote: > On Sun, Mar 14, 2021 at 6:34 PM Peter Stalman wrote: >

Re: [PHP-DEV] [VOTE] noreturn type

turn": "return the exit"). Is there any chance of discussing terms, even if the "never" indication is winning at the moment? Or did I miss this discussion? Thanks! Atenciosamente, David Rodrigues Em sáb., 3 de abr. de 2021 às 23:07, Matthew Brown escreveu: >

Re: [PHP-DEV] Allow commit() without transaction?

, thinking they could safely rollback later if necessary. The exception catches this early on. Regards, David Gebler On Mon, Apr 12, 2021 at 1:07 PM Nikita Popov wrote: > Hi internals, > > Since PHP 8.0, PDO fully supports MySQL transactions -- this means that > inTransaction() will r

Re: [PHP-DEV] [RFC][Draft] Sealed Classes

I don't love this idea, I'm not very fond of the final keyword, either; I've always believed annotations (or attributes in PHP these days) are a better of way of indicating you, as an author of a class, did not write it with inheritability in mind or intended than restricting language features thro

Re: [PHP-DEV] [RFC][Draft] Sealed Classes

2021 at 4:36 PM Mike Schinkel wrote: > > > On Apr 24, 2021, at 7:39 PM, David Gebler wrote: > > I don't love this idea, I'm not very fond of the final keyword, either; > > > I'll start by saying the final keyword caused me a tremendous amount of > heartache b

[PHP-DEV] Method overload support

be used for $userInstance, retest all options (except #2). } 3. Poorly typed functions or methods cannot be overloaded. function printId(User $user) { ... } function printId($user) { ... } // Fatal error Atenciosamente, David Rodrigues

Re: [PHP-DEV] [RFC][Draft] Sealed Classes

On Sun, Apr 25, 2021 at 8:52 PM Mike Schinkel wrote: > > On Apr 25, 2021, at 1:52 PM, David Gebler wrote: > > > > Still, all these problems are solved to the same degree if you add a > > #[Sealed] attribute to a class which has no functional impact. You have > >

Re: [PHP-DEV] [RFC][Draft] Sealed Classes

Yes I agree Chris, this is the same kind of argument I am making. > Note that the *exact* same argument could be made for typing parameters. I can document via a docblock that I expect a given parameter to be a string, or a Request object, or whatever. "There is little to no benefit in expressing

Re: [PHP-DEV] [RFC][Draft] Sealed Classes

Still, it remains that one could have a legitimate, justifiable reason to extend Maybe / some other example, which was not foreseen by its author and is prevented by sealed as a keyword despite the fact this inheritance, correctly implemented, would not break anything, not define an impossible stat

Re: [PHP-DEV] [RFC][Draft] Sealed Classes

On Tue, Apr 27, 2021 at 6:19 PM Pierre wrote: > Le 27/04/2021 à 18:46, David Gebler a écrit : > > What's being proposed in the RFC is a functional change to the language > > whereby attempting to extend a class designated as sealed to a > > non-specified child results

Re: [PHP-DEV] [RFC][Draft] Sealed Classes

On Tue, Apr 27, 2021 at 6:56 PM Levi Morrison wrote: > I think the conversation on final classes being "bad" has gone on long > enough. You don't like final, and you don't want to see more features > like it being added, such as sealed. Point taken. Now please stop > dominating the discussion, th

Re: [PHP-DEV] [RFC][Draft] Sealed Classes

On Tue, Apr 27, 2021 at 11:23 PM Larry Garfield wrote: The two options to prevent such errors are: > > 1. Sealed classes. > 2. Extend Enums into ADTs. > Unless I've misunderstood your example, there is a third option which quite possibly prevents the error in a nicer, easier to reason about, mor

Re: [PHP-DEV] [RFC][Draft] Sealed Classes

entirely moot, though; just like everyone else I take part because I'm very fond of PHP and have an interest in its future. Appreciate those who are willing to hear me out. On Wed, Apr 28, 2021 at 12:00 AM Larry Garfield wrote: > On Tue, Apr 27, 2021, at 5:48 PM, David Gebler wrote: &g

[PHP-DEV] PR for minor bugfix in compact()

t major version? Regards David

Re: [PHP-DEV] PR for minor bugfix in compact()

ge to an existing one (and it went through with the warning condition in the end, anyway). On Wed, 28 Apr 2021, 12:18 G. P. B., wrote: > On Wed, 28 Apr 2021 at 12:12, David Gebler wrote: > >> Hi internals, >> I've opened a PR to cause compact() to throw a TypeError if its

Re: [PHP-DEV] PR for minor bugfix in compact()

; it. > > > > - Chris > > > > Not a lot of chatter about this on the list, but I also agree that this > should be an E_WARNING in 8.1 and promoted to a TypeError in PHP 9. This > is our standard process. > > David, please update the PR, and we'll get it merged. > > Cheers, > Ben > >

Re: [PHP-DEV] [RFC] Partial function application

On Tue, May 11, 2021 at 4:39 PM Larry Garfield wrote: > It looks like the conversation has died down, and it's been two weeks, so > pending any other notable feedback I'll open a vote on this RFC on Thursday > or Friday. > > --Larry Garfield > > > My only query / point of consideration is a very

Re: [PHP-DEV] Disable interactive mode (-a) if readline not available

On Wed, 12 May 2021, 09:13 Nikita Popov, wrote: > > I think we would be better off disabling -a completely if readline is not > available, and exit with a helpful error message. I've opened > https://github.com/php/php-src/pull/6976 to that effect. Does that sound > reasonable? > > Regards, > Nik

Re: [PHP-DEV] [RFC] Partial function application

On Tue, May 18, 2021 at 2:45 PM Larry Garfield wrote: > User-space functions have always accepted more arguments than they're > defined with. They just get dropped off the end silently, unless you use > func_get_args() or variadics. While I know not everyone likes that > "feature", it means tha

Re: [PHP-DEV] [RFC] Partial function application

On Tue, May 18, 2021 at 9:51 PM Rowan Tommins wrote: > Hi David, > > Did you see my message yesterday about the two mental models of the > feature? https://externals.io/message/114157#114492 > > Your expectation there is in line with the "start with an empty closure >

Re: [PHP-DEV] [RFC] Partial function application

On Tue, May 18, 2021 at 11:02 PM Levi Morrison wrote: > Some of the RFC authors have been discussing this a lot based on > feedback. In a [previous message][1] I said we would message the list > when it's ready for re-review. It's still not ready, but we seem to be > driving towards consensus. >

Re: [PHP-DEV] [RFC] First-class callable syntax

On Thu, May 20, 2021 at 8:38 PM Larry Garfield wrote: > > There's been a lot of rapid iteration, experimentation, and rejection. > The most recent alternatives are this one from Levi: > > https://gist.github.com/morrisonlevi/f7cf949c02f5b9653048e9c52dd3cbfd > > And this one from me: > > https://g

Re: [PHP-DEV] Consensus Gathering: is_initialized

On Wed, May 26, 2021 at 11:14 AM Joe Watkins wrote: > Hi internals, > > In response to: https://bugs.php.net/bug.php?id=78480 > > I implemented: https://github.com/php/php-src/pull/7029 > > Not absolutely convinced that it's a good idea, I asked Nikita to review, > and he's unconvinced also and s

Re: [PHP-DEV] json_encode indent parameter

On Wed, 2 Jun 2021, 23:03 Timon de Groot, wrote: > It's not possible to tell json_encode what indentation level should be > used when using > the JSON_PRETTY_PRINT option (2, 4, 8, etc). When generating JSON files > which can be > used/read/edited by users, indentation starts to become a relevant

Re: [PHP-DEV] [RFC] Add parse_query_string as an alternative to parse_str

I really prefer the Sara suggestion, instead of creating a new function to do the same thing. parse_str($str): array. Atenciosamente, David Rodrigues Em qua., 23 de jun. de 2021 às 20:20, Sara Golemon escreveu: > On Wed, Jun 23, 2021 at 5:02 PM Kamil Tekiela > wrote: > > >

[PHP-DEV] pcntl_signal & sa_siginfo

Hi All, Long-time lurker, first time questioner here. I'm currently working on a project wherein I end up forking off many subprocesses, but am trying to keep tabs on the progress of individual forks by having the children send a signal back up to their parent every so often. pcntl_socket, allow

Re: [PHP-DEV] New escaped output operator

age auto-loading at least... I mean, it's still > effectively just abusing classes as pseudo-namespaces, so there is > that - but it would work with e.g. Composer right away, and probably > with many existing static classes? > > Yeah, it's still ugly... > > Ugly, but brilliant! +1 David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Additional context in pcntl_signal handler (was Re: [PHP-DEV] pcntl_signal & sa_siginfo)

sday, June 23, 2016 9:02:55 PM > *To:* PHP internals; bis...@php.net; Joe Watkins; da...@php.net > *Cc:* David Walker > *Subject:* Re: [PHP-DEV] [RFC] Additional context in pcntl_signal handler > (was Re: [PHP-DEV] pcntl_signal & sa_siginfo) > > Hi, > > > To keep maximum

Re: [PHP-DEV] [RFC] Additional context in pcntl_signal handler (was Re: [PHP-DEV] pcntl_signal & sa_siginfo)

On Thu, Jun 23, 2016 at 1:49 PM David Walker wrote: > On Thu, Jun 23, 2016 at 12:26 PM Dmitry Stogov wrote: > >> BTW: I'm not sure what pcntl_sigaction() could return as the "oldact" >> argument..., so may be the original proposal is good enough. >>

Re: [PHP-DEV] Pipe Operator v2

This is a great idea in general, but I think that this kind of operator is not the ideal (expect for $$ that seems very good). Some possibilities to think about: |> (as suggested) seems strange and not very clear, mainly in linear calls --> can be too long, but can make more sense or continuing,

[PHP-DEV] RFC: lazy statements

implementation of this feature. All this ways have a lot of limitations. A hackish example that shows how it should works on current PHP version: http://pastebin.com/cz93wL7n --- I tell more about that here: https://bugs.php.net/bug.php?id=72637 -- David Rodrigues -- PHP Internals - PHP

Re: [PHP-DEV] Pipe Operator v2

e end however, is something I'd rather handle > with the following: > > foo() |> bar($$) |> $baz = qux($$); > > Which is both legal with the syntax as-is, and entirely readable > without adding an extra operator. > > -Sara > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- David Rodrigues -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

The idea is good, but I think that is not pratical in general. --- First point: we should define each new identifier that could be used. It not make clear what this identifier does or even how it should works when a package redefines what it does. For instance: // file1.php set_escape_handler('

Re: [PHP-DEV] RFC: lazy statements

> However, that also means there's an enormous potential for race > conditions. Technically no more than closures now, but the use cases > seem like they'd make it more prevalent. If you "use" by reference, or > use a mutable object, or a service that depends on IO, etc. then the > resulting valu

Re: [PHP-DEV] RFC: lazy statements

Dan Ackroyd wrote: > This looks to solve a problem very similar to the one solved by the > 'Memoize' annotation in HHVM - > https://docs.hhvm.com/hack/attributes/special#__memoize > However the memoize functionality seems a lot clearer to me, as it's > less 'magic'; it doesn't make accessing a var

Re: [PHP-DEV] RFC: lazy statements

Dan Ackroyd wrote: > Yes, but the difference is in the surprise factor. > > Two functions having a circular dependency ==> not too astonishing, > and easy to think about. > > Reading the value of a variable having a circular dependency ==> give > up programming to become a farmer. Okay, so we can

[PHP-DEV] Request for rfc karma

Hi All, I'm desiring to propose my second RFC (thanks bishop for the intro) regarding PR2031 . Seems there has been a couple PR's attempting to raise a notice when accessing non-array-like containers; and I'd like to propose something to attempt to resolv

Re: [PHP-DEV] RFC Karma Request

p.net/bug.php?id=50434. I've added those functions on my > local PHP copy. I would like to make an RFC and a PR for adding it to the > core PHP copy. > > Thanks, > > Will > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: htt

Re: [PHP-DEV] optionally return class name from gettype

'm not sure on the boolean through, I think a new function might be better. > > It's something that can be implemented in userland, but it's also something > that's really often needed. > > Regards, Niklas -- David Rodrigues -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [RFC] E_NOTICE for invalid array container

Hi All, I'm attempting to get involved and hack away at some internals; I figured the best method to do this would be to pick up a bug and do my best at it. So I grabbed #37676. The issue asks to implement an E_(NOTICE|WARNING) when attempting to access scalar values as arrays. cmb alerted me to

Re: [PHP-DEV] [RFC] E_NOTICE for invalid array container

4 Dan Ackroyd wrote: > Hi David, > > On 31 July 2016 at 20:31, David Walker wrote: > > So I want to solicit for more discussion given previous talks. My > > first-attempt RFC for this is at: > > https://wiki.php.net/rfc/notice-for-non-valid-array-container > > &g

Re: [PHP-DEV] RFC Posted for str_begins and str_ends functions

arate functions rather than as a parameter. e.g. >> str_begins(), str_ibegins(), str_ends(), end_iends() > > +1 for having functions for case insensitivity. > I'm not sure if we should have "s". i.e. str_begin"s". > > Regards, > > -- > Yasuo Oh

Re: [PHP-DEV] [RFC] E_NOTICE for invalid array container

anges. -- Dave On Mon, Aug 1, 2016 at 4:27 PM Dan Ackroyd wrote: > Hi David, > > The updated section still doesn't really describe the BC break that well. > > Some people will need to change their code to avoid having notices > raised frequently. How difficult that will be

Re: [PHP-DEV] Tracing exit()

On Thu, Aug 4, 2016 at 12:11 PM Bishop Bettini wrote: > Hi! > > exit (and its doppelganger die) is a hard stop to the engine and there is > little telemetry provided about the circumstances (file, line, message, and > code). In source I control, exit is no big deal: I don't use exit! But in > lib

Re: [PHP-DEV] Function auto-loading

>>> along with Composer auto-loading features will favor a best practice of >>> shipping packages with namespaced functions only, so the performance >>> implications of checking twice would be negligible in practice. >>> >>> Being basically unable to shi

Re: [PHP-DEV] [RFC] E_NOTICE for invalid array container

ocations where this warning might be adversely impacting some of the tests? I know Travis will run tests when I create a PR, but I don't know if it is ensuring all tests are fully run either. Thanks -- Dave On Tue, Aug 2, 2016 at 12:33 PM David Walker wrote: > Dan, > > You're

Re: [PHP-DEV] BC break with rand() where min > max

> Looking for some feedback/opinions on whether anyone else thinks this > should be fixed differently (or not at all). > > N.B. this also changes the behaviour of mt_rand to now accept min > max -- David Rodrigues -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Treats raw types if used as object

ormance? It should be great. In all case, depending of response here, I could try do something, but I don't promises. -- David Rodrigues -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Method compare()

27;, 5) => compare($id, 5, '>') I guess that it could supports all PHP operators: ==, ===, !=, <>, !==, <, >, <= and >=. The spaceship operator does the works too for integers, but not should works if you expects than $a === $b, or when you expects than $a >= $b. -- David Rodrigues -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Method compare()

ndition is client-defined, not developer-defined. For instance: lower, greater, lower-equal, greater-equal, equal In this case, I should implements a switch, where a compare() should works fine. -- David Rodrigues -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Fixing #72733 : Implement getaddrinfo

Hi all, I'm looking to resolve this bug, and thought about 2 means in which to implement the request of exposing C's getaddrinfo() and the addrinfo structure. There's not really an equivalent means to accomplish this in userland without trial&error. So I'm not sure the communities best-practices

Re: [PHP-DEV][RFC] Fixing #72733 : Implement getaddrinfo

On Thu, Aug 11, 2016 at 6:50 PM Bishop Bettini wrote: > I feel the weight of new functions, but really getaddrinfo is meant to > both simplify and unify how sockets are dealt with in the modern era. > socket_getaddrinfo converts the returned linked list into an array of, > essentially, socket con

Re: [PHP-DEV] [RFC][DISCUSSION] Remove utf8_decode() and utf8_encode()

> PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- David Rodrigues -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [RFC][VOTE] E_WARNING on invalid container read-adccess

Hi all, I raised this concept a couple weeks ago to a couple +1's. Discussion was held mostly upon the PR [1], and I went through and documented within the RFC [2]. I'd like to go ahead and open up the RFC to voting to the scope that it is written. -- Dave [1] https://github.com/php/php-src/pu

Re: [PHP-DEV] [RFC][VOTE] E_WARNING on invalid container read-adccess

Will up the ante: I wasn't sure the RFC page on voting didn't really define this, I have no probs with 2/3. On Tue, Aug 16, 2016 at 11:13 AM Levi Morrison wrote: > On Tue, Aug 16, 2016 at 11:09 AM, Dan Ackroyd > wrote: > >> >> > On 16 Aug 2016, at 16:55, David

Re: [PHP-DEV] [RFC][VOTE] E_WARNING on invalid container read-adccess

6 at 12:50 PM Pascal MARTIN, AFUP < mail...@pascal-martin.fr> wrote: > Le 16/08/2016 à 17:55, David Walker a écrit : > > I'd like to go ahead and open up the RFC to voting to the scope > > that it is written. > > Hi, > > At AFUP, we would be +1 on this RFC. > >

[PHP-DEV] [RFC][VOTE]: Implement socket_getaddrinfo family

Hi, I'd like to open voting on my RFC[1] to implement getaddrinfo(). The RFC implements 4 new socket extension functions to aid in the calling, examining, and connect/binding of the addrinfo structure. -- Dave [1] - https://wiki.php.net/rfc/socket_getaddrinfo

Re: [PHP-DEV] [RFC][VOTE] E_WARNING on invalid container read-adccess

On Wed, Aug 24, 2016 at 9:36 AM Bishop Bettini wrote: > On Wed, Aug 24, 2016 at 10:58 AM, David Walker > wrote: > >> I'd like to extend the vote through Sunday evening in the event anyone had >> reservations based on potential performance impact. The RFC is currentl

Re: [PHP-DEV] [RFC][VOTE]: Implement socket_getaddrinfo family

On Wed, Aug 24, 2016 at 9:58 AM Derick Rethans wrote: > On Wed, 24 Aug 2016, David Walker wrote: > > > I'd like to open voting on my RFC[1] to implement getaddrinfo(). The > > RFC implements 4 new socket extension functions to aid in the calling, > > examinin

Re: [PHP-DEV] [RFC][VOTE]: Implement socket_getaddrinfo family

On Wed, Aug 24, 2016 at 9:48 AM Bishop Bettini wrote: > Also, it may be beneficial to elaborate on the scenarios where >> socket_addrinfo is easier to use than socket_* and friends (getservbyname >> for example) and the costs of that ease (eg, behind the scenes DNS queries). > > Most of the get*b

Re: [PHP-DEV] Write down a deprecation policy

On Wed, Aug 24, 2016 at 3:46 PM Stanislav Malyshev wrote: > Hi! > > > * Explicit remaining time to live of a deprecated feature (ie. in > > which future version of php this deprecated functionality will be > > dropped) > > I don't think we should be in a rush to drop deprecated things. Java, >

[PHP-DEV] Allow infinity integer length

float, $bits), for instance). But it can be part of another discussion. -- David Rodrigues -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC][VOTE] E_WARNING on invalid container read-adccess

esday, August 31, 2016 10:10:23 AM > > To: Dmitry Stogov > > Cc: Christoph M. Becker; PHP Internals List; Nikita Popov; David Walker > > Subject: Re: [PHP-DEV] Re: [RFC][VOTE] E_WARNING on invalid container > read-adccess > > > > > > Hi Dmitry, > > >

Re: [PHP-DEV] Re: [RFC][VOTE] E_WARNING on invalid container read-adccess

On Wed, Aug 31, 2016 at 7:48 AM David Walker wrote: > I too get Dmitry's result. As the left hand side is an error-zval, and > the right hand is null, it explodes. Yes, the hackish way I try and > resolve things was to check opcodes around the current one, which I should > ha

Re: [PHP-DEV] Re: [RFC][VOTE] E_WARNING on invalid container read-adccess

On Wed, Aug 31, 2016 at 7:49 AM David Walker wrote: > On Wed, Aug 31, 2016 at 7:48 AM David Walker wrote: > >> I too get Dmitry's result. As the left hand side is an error-zval, and >> the right hand is null, it explodes. Yes, the hackish way I try and >> resolv

[PHP-DEV] Re: [RFC][VOTE]: Implement socket_getaddrinfo family

On Wed, Aug 24, 2016 at 9:26 AM David Walker wrote: > Hi, > > I'd like to open voting on my RFC[1] to implement getaddrinfo(). The RFC > implements 4 new socket extension functions to aid in the calling, > examining, and connect/binding of the addrinfo structure. > >

Re: [PHP-DEV] Re: [RFC][VOTE] E_WARNING on invalid container read-adccess

On Thu, Sep 1, 2016 at 1:03 AM Dmitry Stogov wrote: > Hi David, > > I would propose to cancel voting and restart it when the good > implementation is found. > > Otherwise, people may rise their hands for something that can't be > implemented in good enough way. > &

Re: [PHP-DEV] Re: [RFC][VOTE] E_WARNING on invalid container read-adccess

te: > Looking forward won't always work out of the box. > > Take into account possible TICK opcodes, BEGIN/END silence, debugging > opcodes. > > It's probably easier to throw exception, instead of recovery, but this is > a BC break, and might be done only in 8.0.

Re: [PHP-DEV] Re: [RFC][VOTE] E_WARNING on invalid container read-adccess

On Fri, Sep 2, 2016 at 9:28 AM Christoph M. Becker wrote: > On 02.09.2016 at 16:57, David Walker wrote: > > > Poking around, I'm must not be understanding how TICK opcodes would > > negatively impact the lookahead. It may be my newness, but the way I'm &g

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

On Fri, Sep 2, 2016 at 1:33 PM Davey Shafik wrote: > Hi internals, > > I'd like to introduce a new RFC to deprecate pear/pecl (in 7.2, and remove > in 8.0), as well as add composer/pickle (optional in 7.2, default in 7.3+) > in their place. > > https://wiki.php.net/rfc/deprecate-pear-include-comp

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

e (eg TCPDF)... That said if you've got some other style, just register a loader for it and get on with it. Sounds to me like your problem isn't with Composer per se, but autoloading in general? Cheers, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Super-types declaration

There are a RFC for union-types (https://wiki.php.net/rfc/union_types) that was declined, but I see that it is a recurring question here (today, for instance, David Eddy tried to start this discussion again with the same concept). Then, I don't know if the problem is the union methodology

Re: [PHP-DEV] Do You think PHP's SOAP client should have an option to virtuallyAdd (for XSD imports!) missing end-slash in the URI to WSDL? I do!

I think it should not. Your pull request fixes a problem in that WSDL. The WSDL is located at the URL `https://pg.eet.cz/eet/services/EETServiceSOAP/v3?wsdl`. It references an XML Schema file at `EETXMLSchema.xsd`, which is a relative location, so it's looked for relative to the containing docu

[PHP-DEV] [RFC] Bug #72811 - Replacing parse_url()

Hi all, A couple weeks back I took a look at 72811[1]. The bug being that parse_url() didn't accept IPv6 addresses without a scheme, like it did for IPv4 addresses. I attempted to patch the specific bug within the scope of how parse_url() was processing URI's. After opening a PR for the resouti

[PHP-DEV] Re: [RFC] Bug #72811 - Replacing parse_url()

On Thu, Oct 6, 2016 at 11:19 AM Christoph M. Becker wrote: So, I basically see two options: * wait until PHP 8 (whenever that'll be released) and switch the implementation of parse_url() then – what might delay the adoption of PHP 8 * add a new function in PHP 7.2 (maybe called pars

Re: [PHP-DEV] [RFC] Bug #72811 - Replacing parse_url()

On Thu, Oct 6, 2016 at 10:13 PM Stephen Reay wrote: > Could the new URL parser be exposed via a third parameter to parse_url, > which defaults to false/off in 7.2 (or whenever its added) but then > defaults to true in 8.0? I, personally, would be opposed to this. Firstly, it doesn't alert user

Re: [PHP-DEV] [RFC] Bug #72811 - Replacing parse_url()

Hi Nikita, On Fri, Oct 7, 2016 at 4:37 AM Nikita Popov wrote: > Are you aware of the WHATWG URL standard [1]? Quoting the first goal > statement: > > > Align RFC 3986 and RFC 3987 with contemporary implementations and > obsolete them in the process. (E.g., spaces, other "illegal" code points, >

<    5   6   7   8   9   10   11   12   13   14   >