On Wed, Nov 29, 2023 at 7:19 AM Stephen Reay
wrote:
> So no, I don't think compact() should be deprecated, what I think *should*
> happen, is to promote the current warning on undefined variables, to an
> error, as per https://wiki.php.net/rfc/undefined_variable_error_promotion.
> Whether this
I wouldn't support this, personally. I'm not a voter but I mean just in
terms of gauging community feel about the proposal, without unnecessarily
repeating what's already been said I just want to register that I'm in
agreement with Larry and Kamil's comments.
What static classes would achieve
On Sun, Nov 12, 2023 at 8:20 PM Andreas Hennings
wrote:
> So to me, this alone is an argument to implement this natively.
> The other argument is that it is kind of sad how the current functions
> don't behave as one would expect.
I'd expect there to be a larger and proportionately increasing
On Sat, Nov 11, 2023 at 6:05 PM Andreas Hennings
wrote:
> Hello internals,
> I noticed that array functions like array_diff(), array_intersect()
> etc use weak comparison.
>
>
That's not quite correct. Using the example of array_diff, the comparison
is a strict equality check on a string cast of
On Sun, Nov 5, 2023 at 1:37 PM Oladoyinbo Vincent
wrote:
> Hello Internals,
>
> I was wondering if php could introduce this feature or if any experienced C
> dev here can work on the implementation of this feature.
>
>
I think this is a much bigger issue than bikeshedding over syntax. The idea
On Fri, Sep 8, 2023 at 2:12 PM Lanre Waju wrote:
> Dear PHP Internals,
>
> I am writing to propose a new feature for PHP that introduces the
> concept of structs. This feature aims to provide a more concise and
> expressive way to define and work with immutable data structures. Below
> is a
What's the difference between this and what was proposed in
https://externals.io/message/120799 ? I don't get why this wouldn't require
an RFC.
On Fri, Jul 14, 2023 at 3:08 AM Dusk wrote:
> 2) These expansions should probably be disabled by INI_SCANNER_RAW; that
> flag already disables certain other types of value interpolation. (Oddly,
> it doesn't disable expansion of constants either; that might be worth
> revisiting as well.)
On Thu, Jul 13, 2023 at 10:25 PM Sergii Shymko wrote:
> For instance, functions parse_ini_string() and parse_ini_file() do support
> the aforementioned env variables syntax, because the underlying code is
> reused. That means that these functions can potentially be exploited to
> read sensitive
On Wed, Jul 12, 2023 at 5:01 AM G. P. B. wrote:
>
> Maybe the resistance to the proposal would be far less if the RFC, and
> implementation, would check at compile time that the default
> implementations only rely on known existing functions available to the
> interface.
>
I asked in the
Looks - sadly to me - like this isn't going to pass. I don't have vote
karma and if I did it wouldn't make a difference to the outcome, but it
would be really good for those of us who can't vote on the feature to hear
from some of the people who voted against it why they chose no. The
feedback
On Tue, Jul 4, 2023 at 8:30 PM Nuno Maduro wrote:
> Hi Internals,
>
> I am writing to request karma privileges to vote on PHP RFCs.
>
>
I'm not a voter and have no influence here but from previous discussions
which have come from similar requests, I don't think you're likely to get
this. The
On Tue, 20 Jun 2023, 04:10 Levi Morrison, wrote:
> > I like the idea of this RFC - in fact it's one which has been near top of
> > my wishlist for PHP language features for a long time - but I think this
> is
> > an issue with the proposed implementation which at the very least
> warrants
> >
On Mon, Jun 19, 2023 at 9:53 PM Rowan Tommins
wrote:
> On 19/06/2023 20:20, David Gebler wrote:
> > Okay, thanks. That's really quite significant, since it changes the
> feature
> > to one which could allow changes made to interfaces to adversely impact
> > existing
On Mon, Jun 19, 2023 at 3:53 AM Levi Morrison
wrote:
>
> No, there's no attempt to ensure the method body adheres to calling
> the public interface. Due to PHP's possible dynamic behaviors, I don't
> think it's reasonable to attempt to enforce it at compile-time. I'm
> not sure it's worth the
On Thu, Jun 15, 2023 at 4:48 AM Levi Morrison via internals <
internals@lists.php.net> wrote:
>
> I am moving my RFC for interface default methods to discussion:
> https://wiki.php.net/rfc/interface-default-methods.
>
>
Can I ask, the RFC doesn't say - does your implementation ensure default
programming
and "best practices". And my views on those things are probably quite
anodyne, but the margin for difference in good opinions is more than enough
that I don't want to go there.
-Dave
On Sun, May 28, 2023 at 5:03 PM Larry Garfield
wrote:
> On Sun, May 28, 2023, at 6:52 AM, David
On Sun, May 28, 2023 at 10:33 AM Rowan Tommins
wrote:
> I don't follow. If a property is public, then code outside the class can
> rely on being able to access it. That seems to me to be a contract between
> the class and its users, not an implementation detail - e.g. removing the
> property, or
On Sat, May 27, 2023 at 9:44 PM Zoltán Fekete
wrote:
> Abstract class could help this but it’s like using a
> tube wrench for a nut. Also one class can extend only one abstract class.
> By
> simply defining interfaces with properties would save a lot of boilerplate
> code
> and there would be no
On Sat, May 27, 2023 at 6:24 PM Larry Garfield
wrote:
> On Sat, May 27, 2023, at 1:39 AM, Nick Humphries wrote:
> > Hello internals,
> >
> > Based on a few discussions I've had recently, my team and I couldn't
> > think of any reason why we shouldn't have properties on interfaces as
>
>
I
On Tue, May 23, 2023 at 9:27 PM Tim Düsterhus wrote:
> Just to make sure there is no misunderstanding I'd like to clarify that
> the proposed check of this RFC is not a runtime error. It's a compile
> time error, just like the check for incompatible method signatures
> during inheritance. In
On Sun, May 21, 2023 at 4:21 PM Larry Garfield
wrote:
>
> Having recently been bitten by floor() returning a float even though the
> value that comes back is logically an int, I would be fully in support of
> "and returns an int" versions of these functions in core.
>
What about adding a third,
On Mon, May 22, 2023 at 1:01 PM Dan Ackroyd wrote:
> Even for those who use static analysis, most (afaik) don't have it
> running constantly in local development and this RFC would prevent
> people wondering why their code is behaving surprisingly before it is
> static analysed.
>
It takes care
On Thu, May 18, 2023 at 9:12 AM Marco Pivetta wrote:
>
> Would it perhaps make sense to have this in userland first, in phpstan or
> psalm plugins, to see if there is interest?
>
100% this in my view; this is exactly the kind of check which you would
expect to be done at the static analysis
On Wed, May 17, 2023 at 4:31 PM Chase Peeler wrote:
> Definitely a useful feature, but not sure it needs to be a core function.
>
>
I feel the same. There are countless useful utility functions which could
exist in core, many of which are even widely used and commonly reinvented
as userland
On Thu, Apr 20, 2023 at 6:25 PM Larry Garfield
wrote:
> ## The options
>
> There's three ways we've come up with that this design could be
> implemented. In concept they're not mutually exclusive, so we could do
> one, two, or three of these. Figuring out which approach would get the
> most
On Mon, Jan 9, 2023 at 9:42 PM Derick Rethans
wrote:
> On 9 January 2023 18:49:28 GMT, Sara Golemon wrote:
> >I've been working with JWTs lately and that means working with Base64URL
> >format. (Ref: https://www.rfc-editor.org/rfc/rfc4648#section-5 )
> >This is essentially the same thing as
On Mon, Dec 12, 2022 at 10:20 PM Dan Liebner wrote:
> As the RFC points out, "Some languages, such as JavaScript, do not consider
> accesses to undefined array keys to be an error condition at all, and allow
> such an operation to be performed silently."
>
It is by definition an error condition
On Tue, Oct 11, 2022 at 12:05 AM David Rodrigues
wrote:
> The idea is that the experimental features are exclusively something that
> the PHP team has voted for (approved) and that will be part of the language.
>
So they're not experimental features, they're accepted RFCs, maybe with a
lower
My two cents...
Why can't "common users" install a PECL extension? It's not a difficult,
obscure or undocumented process.
I can accept the reasoning
> Apply a PECL strategy to try experimental features might not be the
convenient way always, for example, if we create a new ... sensitive ini
On Tue, Oct 4, 2022 at 11:34 AM Rowan Tommins
wrote:
> The "notorious" thing I know is that validating e-mail addresses is next
> to impossible because of multiple overlapping standards, and a huge
> number of esoteric variations that might or might not actually be
> deliverable in practice. If
On Mon, Oct 3, 2022 at 11:29 AM Max Semenik wrote:
>
> Is there a compelling need to have this in the core, as opposed to
> Composer packages? The ecosystem has changed a lot since the original
> function was introduced.
>
I don't know that there is, I suspect the answer is probably not and
On Sun, Oct 2, 2022 at 4:10 PM Larry Garfield
wrote:
> The filter extension has always been a stillborn mess. Its API is an
> absolute disaster and, as you note, its functionality is unclear at best,
> misleading at worst. Frankly it's worse than SPL.
>
> I'd be entirely on board with
On Sat, Sep 10, 2022 at 3:05 PM juan carlos morales <
dev.juan.mora...@gmail.com> wrote:
> I also agree that increasing the size to something bigger than 8M
> might not be a good idea; I can imagine that a value bigger than 8M
> (like 50M) will cause an impact in hosting platforms specially,
On Wed, Sep 7, 2022 at 10:47 PM Kris Craig wrote:
> On Wed, Sep 7, 2022 at 11:38 AM juan carlos morales <
> dev.juan.mora...@gmail.com> wrote:
>
> > I looked for a potential problem out of doing such a change but I could
> not
> > find anything.
> >
>
> Then I'd say it's a no-brainer. The
Juan,
You can always offer two votes on the RFC - one for the function itself,
then one for should it return boolean or return an int representing the
json_last_error constants and let it be decided that way.
I think on the whole, I agree with the sentiment that returning boolean and
checking
On Fri, Aug 26, 2022 at 6:29 PM Kamil Tekiela wrote:
> What is the reasoning behind the name? I can't find it explained in the
> RFC. What about other alternatives like is_json or validate_json?
>
The name json_validate makes most sense to me; it groups itself together
nicely with the other
Having actually compiled the branch and tried it out, I have to say
regardless of whether validating arbitrarily large blocks of JSON without
being interested in the contents is a common or more niche use case, the
memory savings ARE highly impressive. I had thought that because the
function was
I'm not a voter on RFCs so my input may be largely irrelevant here but for
discussion purposes:
I remain unconvinced regarding the justification for this proposal. I'm not
saying there's a strong reason to NOT implement it, but I'm not convinced
it's really going to be a significant benefit to
On Tue, Aug 23, 2022 at 6:27 PM Daniel Wolfe wrote:
>
> If we do go down the operator route, however, what tokens should be
> chosen? `%%` makes since for floor modulo, but `//` is already used for
> comments.
>
Yeah I appreciate it is tricky, because // is pretty much the only
obviously
On Mon, Aug 22, 2022 at 4:22 AM Daniel Wolfe wrote:
> For the first four instances, the function works as intended since the
> timestamps are non-negative numbers. However, for the fifth example,
> since the date is before 1970, the timestamp is going to be negative
> resulting in an ostensible
On Sun, Jul 31, 2022 at 4:41 PM Larry Garfield
wrote:
> So the core argument, it seems, is "there's lots of user-space
> implementations already, hence demand, and it would be
> better/faster/stronger/we-have-the-technology to do it in C."
>
There's innumerable features implemented in userland
On Sat, Jul 30, 2022 at 3:01 PM Nikita Popov wrote:
> On Fri, Jul 29, 2022 at 4:27 PM juan carlos morales <
> dev.juan.mora...@gmail.com> wrote:
>
> > I am following the RFC guideline for the first time. (
> > https://wiki.php.net/rfc/howto)
> >
> > As suggested there, I am here to get a feeling
On Sun, Jun 5, 2022 at 9:24 AM shinji igarashi wrote:
> Hello everyone,
>
> I'd like to propose adding a new closing tag `=?>` to the language.
>
> PHP currently removes the newline character immediately following
> the closing tag `?>`.
>
Personal opinion, seems like a classic sledgehammer on
On Wed, Jan 5, 2022 at 11:05 PM Larry Garfield
wrote:
> On Wed, Jan 5, 2022, at 2:35 PM, Chase Peeler wrote:
>
> For point 2, that's mainly useful as a way to signal to other developers
> "hey, this trait has all but one method of the LoggerInterface, that's how
> you'd use it", and to signal
On Tue, Jan 4, 2022 at 10:35 PM Kirill Nesmeyanov wrote:
> How relevant do you think this idea/proposal is? And what possible
> problems or solutions will this entail in the future?
>
I'm not convinced there's a reasonable need for it. The very nature of
finding yourself in a situation where
On Mon, Jan 3, 2022 at 5:38 PM Nikita Popov wrote:
> On Mon, Jan 3, 2022 at 1:14 AM Jordan LeDoux
> wrote:
>
> > Hello internals,
> >
> > I've opened voting on
> > https://wiki.php.net/rfc/user_defined_operator_overloads. The voting
> will
> > close on 2022-01-17.
> >
> > To review past
On Tue, Dec 21, 2021 at 6:59 PM Christoph M. Becker
wrote:
> Hi all,
>
> a while ago it has been reported[1] that our header() function actually
> allows arbitrary status codes, which may even overflow. Of course, that
> makes no sense, since the status code is supposed to be a three digit
>
On Tue, Oct 5, 2021 at 3:45 PM Nikita Popov wrote:
> On Tue, Oct 5, 2021 at 4:08 PM Côme Chilliet wrote:
>
> > Le lundi 4 octobre 2021, 10:09:12 CEST Nikita Popov a écrit :
> > > If we make this change, I would however suggest to also support "false"
> > as
> > > a standalone type. I think this
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
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
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:
>
>
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.
>
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
> and add things" model; the
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
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,
>
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
Great, that's been updated, build in progress (relevant tests passing
locally). I'd have preferred TypeError but appreciate there being a
consistent convention to follow. These kind of small fixes are also about
me becoming more familiar with typical conventions in the engine - some of
this stuff
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 parameter
Hi internals,
I've opened a PR to cause compact() to throw a TypeError if its parameters
are not valid, which I consider to be a fix for what is effectively a bug
whereby logical errors in user code can be silently swallowed.
GPB has done an initial review and left a comment
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:
> > On Tue, Apr 27, 2021 at 11:23 PM Larry Garfield
> > wrote:
> >
&
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,
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,
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 in a
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
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
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
> >
te:
>
>
> 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 because it was used on a class in a framework that
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
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 report the actua
> Would it make sense to have both options?
If you have the wrapper pattern, you already have both options. This would
be my preferred way of doing it but harder to implement, particularly in
any way which significantly mimics Python's way of doing it.
> One problem with the wrapper pattern is
The information you were given on StackOverflow is somewhat misleading,
since it is referring to the behaviour of PDO::quote(), not anything to do
with binding parameters. The referenced bug report is indeed not a bug.
Still, I don't really use Postgres but a quick smoke test indicates you're
not
rry Garfield
wrote:
> On Sun, Mar 14, 2021, at 7:33 AM, David Gebler wrote:
> > Hi Ben,
> > I have been looking at your #[Deprecated] PR to get an idea of where to
> > start with implementing this, I think Peter's suggestion of how it might
> > look syntactically is a
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 still
>>
at 10:51 PM Peter Stalman wrote:
> Hi David,
>
> This sounds a lot like Asect Oriented Programming. Have you looked into
> that?
>
> PHP framework:
> https://github.com/goaop/framework
>
> PECL extension:
> https://aop-php.github.io/
>
> Thanks,
> Peter
>
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 similar constructs
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
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 reite
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
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/
;
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 2021 21:41:40 +
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:
>
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
.
- Adds function fsync() on Windows with fdatasync() available as an alias
PR ref https://github.com/php/php-src/pull/6650
Regards,
David Gebler
nt
> concerns or objections?
>
> Thanks.
>
> Dave
>
> On Mon, Feb 1, 2021 at 5:35 PM David Gebler wrote:
>
>> Hi internals,
>> I have updated the GitHub PR and wiki RFC to also include an
>> implementation of fdatasync.
>>
>> On another note, I note
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
> 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
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,
, 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/probably
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/probably
ignore lower error levels and emitting a warning for a previously common
at 5:35 PM David Gebler wrote:
> Hi internals,
> I have updated the GitHub PR and wiki RFC to also include an
> implementation of fdatasync.
>
> On another note, I note my PR builds are failing on MACOS_DEBUG_NTS with a
> test in ext/zend_test/tests/observer_error_05.phpt- th
> We tried that. The `enum` keyword precludes any class or interface being
called `Enum`, even internally.
Enumerable, Enumerated, Enumerator?
On Mon, Feb 1, 2021 at 7:30 PM Larry Garfield
wrote:
> On Mon, Feb 1, 2021, at 11:48 AM, Alexandru Pătrănescu wrote:
>
>
> > >
if anyone can shed any light on
this? I'm seeing it on some other open PRs too so I'm guessing it's a known
issue? Cheers.
David Gebler
davidgeb...@gmail.com
On Sat, Jan 30, 2021 at 6:34 PM David Gebler wrote:
> Updated the PR https://github.com/php/php-src/pull/6650 following comment
>
Updated the PR https://github.com/php/php-src/pull/6650 following comment
from Nikita, added basic tests, would appreciate further review from
contributors, have updated the RFC https://wiki.php.net/rfc/fsync_function to
under discussion, cheers.
David Gebler
davidgeb...@gmail.com
On Sat, Jan
to standard,
as well as tests and documentation) which I would like to open up for
review and discussion.
Thanks.
David Gebler
davidgeb...@gmail.com
Thanks, my browser was automatically populating the wrong email, I've now
registered. Apparently I need to request karma now? Username dwgebler.
On Sat, Jun 6, 2020 at 12:19 AM Christoph M. Becker
wrote:
> On 06.06.2020 at 00:00, David Gebler wrote:
>
> > As a side-note, I am unable
As a side-note, I am unable to register a wiki.php.net account to raise
this RFC, I get a very unhelpful error message which just says "That wasn't
the answer we were expecting" when I submit my details. Anyone have any
idea what that is?
On Thu, Jun 4, 2020 at 3:19 PM David Geb
on Windows, but fsync() is. fdatasync() is
available on UNIX builds.
fdatasync() on Windows is an alias of fsync(), on UNIX fdatasync() is as
expected.
Only fsync() is implemented for both Windows and Unix.
-Dave
On Wed, 3 Jun 2020, 11:16 Nikita Popov, wrote:
> On Mon, Jun 1, 2020 at 6:57 PM Da
big is the effort required to implement this
feature.
On Mon, Jun 1, 2020 at 8:47 PM Christian Schneider
wrote:
> Am 01.06.2020 um 18:56 schrieb David Gebler :
> > It seems to me an odd oversight that this has never been implemented in
> PHP
> > and means PHP has no way to perfo
program buffers to the operating system *and tell the operating system to
immediately flush its buffer to disk too*", so when this function returns
success status you can be as reliably sure as possible that data has been
physically persisted. fflush does not provide this assurance.
On Mon, 1 Jun 2020
1 - 100 of 102 matches
Mail list logo
