On Sun, Oct 13, 2024 at 5:03 PM Valentin Udaltsov <
udaltsov.valen...@gmail.com> wrote:
> On Mon, 14 Oct 2024 at 01:28, Jordan LeDoux :
> > Backwards compatible has never, in any work I've done through my entire
> career, meant something like "if you take old code and
On Fri, Oct 11, 2024 at 3:34 AM Rob Landers wrote:
> On Fri, Oct 11, 2024, at 12:20, Jonathan Vollebregt wrote:
>
> > A "proper" implementation won't break, but there may be subtle ways that
> "improper" implementations will break and thus it should be considered a BC
> break.
>
> This thread is
On Tue, Sep 17, 2024 at 6:49 PM Larry Garfield
wrote:
> On Tue, Sep 17, 2024, at 3:14 PM, Jordan LeDoux wrote:
>
> >> I think it's absolutely possible - and desirable - to choose a
> philosophical position on that spectrum, and use it to drive design
> decisions
t for those the readability improvement would be huge.
> Also, being able to override comparison operators for objects would be very
> useful, because currently using == and === with objects is almost never
> helpful or sufficient.
>
> And I support that. Just have developers or yourself
On Tue, Sep 17, 2024 at 12:27 PM Rowan Tommins [IMSoP]
wrote:
> On 17/09/2024 18:15, Jordan LeDoux wrote:
>
>
> 1. Are we over-riding *operators* or *operations*? That is, is the user
>> saying "this is what happens when you put a + symbol between two Foo
>> objec
On Tue, Sep 17, 2024 at 10:55 AM Davey Shafik wrote:
>
>
> On Sep 17, 2024, at 10:15, Jordan LeDoux wrote:
>
>
>
> On Tue, Sep 17, 2024 at 1:18 AM Rowan Tommins [IMSoP] <
> imsop@rwec.co.uk> wrote:
>
>> On 14/09/2024 22:48, Jordan LeDoux wrote:
>&
On Tue, Sep 17, 2024 at 2:56 AM Lynn wrote:
>
>
> On Sat, Sep 14, 2024 at 11:51 PM Jordan LeDoux
> wrote:
>
>> Hello internals,
>>
>> This discussion will use my previous RFC as the starting point for
>> conversation: https://wiki.php.net/rfc/user_defined_
On Tue, Sep 17, 2024 at 2:14 AM Mike Schinkel wrote:
> > On Sep 17, 2024, at 1:37 AM, Jordan LeDoux
> wrote:
> > On Mon, Sep 16, 2024 at 9:35 PM Mike Schinkel
> wrote:
> >
> > Yes, if constraints of the nature I propose below are adopted.
> >
> >
On Tue, Sep 17, 2024 at 1:18 AM Rowan Tommins [IMSoP]
wrote:
> On 14/09/2024 22:48, Jordan LeDoux wrote:
> >
> > 1. Should the next version of this RFC use the `operator` keyword, or
> > should that approach be abandoned for something more familiar? Why do
> > y
On Mon, Sep 16, 2024 at 9:35 PM Mike Schinkel wrote:
>
> Yes, if constraints of the nature I propose below are adopted.
>
> The biggest problem I have with operator overloads is that — once added —
> all code could potentially be "infected" with operator overloads. However,
> if the developer *us
On Mon, Sep 16, 2024 at 6:08 AM Rob Landers wrote:
> On Mon, Sep 16, 2024, at 09:47, Jordan LeDoux wrote:
>
> The reason for this was to prevent developers from creating situations
> where `5 > $foo` is true and `5 < $foo` is true.
>
>
> Just to point out: currently, P
On Mon, Sep 16, 2024 at 6:52 AM Bilge wrote:
>
>
> On Mon, 16 Sept 2024, 15:28 someniatko, wrote:
>
>> On behalf of all struggling PHP developers who would like to implement
>> patterns like Value Objects, with custom equality criterias
>>
>
> I seriously doubt anyone is struggling without this,
On Sun, Sep 15, 2024 at 9:12 PM Larry Garfield
wrote:
>
> The "multiply by -1 for <=>" bit I don't fully understand the point of.
> The RFC tries to explain, but I don't quite grok it.
>
>
I will perhaps respond with more detail to the rest of your message later,
but I wanted to address this spec
On Sat, Sep 14, 2024 at 2:45 PM Barel wrote:
> Hi
>
> For C/C++ development I usually use CLion from Jetbrains but I tried to
> use it with php-src and was unable to get it to work properly. CLion really
> insists on using CMake and has only quite limited support for makefiles.
> After trying to
Hello internals,
This discussion will use my previous RFC as the starting point for
conversation: https://wiki.php.net/rfc/user_defined_operator_overloads
There has been discussion on list recently about revisiting the topic of
operator overloads after the previous effort which I proposed was dec
On Tue, Aug 20, 2024 at 6:02 AM Arnaud Le Blanc wrote:
> Hi Bob,
>
> On Tue, Aug 20, 2024 at 12:18 AM Bob Weinand wrote:
> > The fluid Arrays section says "A PoC has been implemented, but the
> performance impact is still uncertain". Where may I find that PoC for my
> curiosity? I'm imagining th
On Wed, Jul 10, 2024 at 1:08 PM Michael Morris wrote:
>
>
> I'm in no rush - though it might not seem that way. I don't see this being
> able to land before PHP 10. I'm pessimistic about the scope of these
> changes. It can be done - and pieces have often been discussed before, but
> they peter o
On Tue, Jul 9, 2024 at 11:42 PM Mike Schinkel wrote:
> [snip]
> My one useful takeaway from your email — except that I already knew that —
> was the need to figure out how PHP can handle multiple symbol tables.
> Beyond that, your take your own advice and spare us (me) from your contempt
> and co
On Tue, Jul 9, 2024 at 10:47 AM Tim Düsterhus wrote:
> Hi
>
> On 7/8/24 11:36, Jordan LeDoux wrote:
> > I suspected the same thing when I was doing my arbitrary precision
> library,
> > but I actually have yet to find a test case in all my unit tests where
> this
>
On Mon, Jul 8, 2024 at 2:42 AM Rowan Tommins [IMSoP]
wrote:
>
>
> On 8 July 2024 04:25:45 CEST, Jordan LeDoux
> wrote:
> >I think it's strange that this discussion has driven deep down the tangent
> >of versioning...
> [...]
> >Things like separating glob
On Sun, Jul 7, 2024 at 8:19 PM Saki Takamachi wrote:
> Hi Juliette,
>
> > Hi Saki,
> >
> > Just wondering: why `int|string` instead of `float|string` ?
> > In my experience, floats are the more pertinent type for which to use
> the BCMath extension.
> >
> > Smile,
> > Juliette
>
> Since floating
On Wed, Jul 3, 2024 at 5:18 PM Michael Morris wrote:
> Hello all. Hitting reset again as the primary problem at hand has become
> clear. Let's recap it.
>
> Autoloading is great for loading packages, but it can't load different
> versions of the same package at the same time. Why would you want
On Sat, Jul 6, 2024 at 1:09 AM chopins xiao wrote:
> The reason I'm not so polite is because I'm so angry. Firstly, the
> Deprecate functions with overloaded signatures RFC's approach to FFI
> recommendations is unfounded, and secondly, the PR commit(
> https://github.com/php/php-src/commit/4acf
On Tue, Jul 2, 2024 at 4:06 AM Saki Takamachi wrote:
> Hi all,
>
> > Hi internals,
> >
> > Created a follow-up RFC for the BCMath\Number class. This RFC also
> contains proposed changes to GMP's bool cast. I have proposed similar
> changes to BCMath, so for procedural efficiency I have combined t
On Mon, Jul 1, 2024 at 11:09 AM Mike Schinkel wrote:
>
> > and I'm fairly certain after keeping up with the thread that it is
> almost universally not what people want. Most people just want the toolbox
> be "finished" so to speak, not get a completely new one in addition that
> has no compatibil
On Fri, Jun 28, 2024 at 12:55 PM Rob Landers wrote:
>
>
> 3. The private/protected distinction is fairly meaningless for the
> functions that implement overloads, because the privacy of the function is
> ignored completely when it is executed to evaluate an operator.
>
>
> Hmm. I like the idea of
On Fri, Jun 28, 2024 at 10:47 AM Rob Landers wrote:
> Hello internals,
>
> I'd like to introduce a new RFC:
> https://wiki.php.net/rfc/operator_overrides_lite which extends the GMP
> extension to support a limited set of operator overriding to developers.
> It's designed to be limited and relativ
On Thu, Jun 27, 2024 at 2:41 PM Jim Winstead wrote:
> On Thu, Jun 27, 2024, at 2:14 PM, Jordan LeDoux wrote:
>
> On Thu, Jun 27, 2024 at 12:53 PM Jim Winstead
> wrote:
>
>
> On Wed, Jun 26, 2024, at 7:15 PM, Michael Morris wrote:
>
> PHP User Modules are php file
On Thu, Jun 27, 2024 at 2:35 PM Rob Landers wrote:
>
>
> On Thu, Jun 27, 2024, at 06:07, Saki Takamachi wrote:
>
>
> I agree with Gina. Being able to change the class of a computed result of
> an inherited child class causes several problems.
>
> The points raised in the `BCMath\Number` discussio
On Thu, Jun 27, 2024 at 2:14 PM Rob Landers wrote:
> On Thu, Jun 27, 2024, at 05:39, Gina P. Banyard wrote:
>
> On Wednesday, 26 June 2024 at 18:24, Rob Landers
> wrote:
>
> Hello internals,
>
> I've had this little library for a while (
> https://github.com/withinboredom/time), mostly as a plac
On Thu, Jun 27, 2024 at 12:53 PM Jim Winstead
wrote:
> On Wed, Jun 26, 2024, at 7:15 PM, Michael Morris wrote:
>
> PHP User Modules are php files that are brought into the runtime through a
> new parser that is able to generate faster and more concise runtime code by
> removing support for proble
On Thu, Jun 27, 2024 at 11:13 AM Deleu wrote:
> Who would build it is an extremely key aspect of making changes to PHP.
> Ideas are hard enough to survive the RFC process when there's already an
> implementation. Finding a sponsor to work on this would be the first step.
>
> ...
>
I like the ide
I am interested to see what people say to this. One of the primary reasons
I was given by no voters on my operator overload RFC was that it was not
useful enough to justify the complexity. Since then however we have had a
steady stream of people on list presenting their use cases that have run
into
On Wed, Jun 19, 2024 at 12:16 PM Claude Pache
wrote:
>
> Second, “TowardsPositiveInfinity” is just a mouthful synonym for “Up”. You
> could just name it:
>
> Round::Up
>
> At this point, you may invoke either Hamming or Levenshtein and compare it
> negatively with `Round::HalfUp`. Yes there is a
On Sun, Jun 2, 2024 at 2:27 PM Jorg Sowa wrote:
> > It should also be noted that ceil/floor is very English specific
> terminology that may not be immediately obvious to non-English speakers,
> thus my preference for using some variation of towards positive/negative
> infinity.
>
> This statement
On Thu, May 16, 2024 at 1:32 PM Patrik Václavek wrote:
> Introduction
> *
>
> This RFC proposes a new feature in PHP: type guards for classes (or
> interfaces). This feature aims to simplify and standardize the process of
> verifying that a variable is an instance of a specific class,
On Sat, Apr 27, 2024 at 11:04 PM Alexander Pravdin
wrote:
>
> All builtin functions that currently accept float also accept decimal.
> So users don't need to care about separate function sets, and PHP
> developers don't need to maintain separate sets of functions. If any
> of the parameters is de
On Sun, Apr 14, 2024 at 9:50 AM Tim Düsterhus wrote:
>
> I don't think it should be in a namespace. The name is sufficiently
> unique and clear. Without a broader concept for the namespace, we
> probably should not introduce one.
>
>
+1
For this, I don't think a namespace is necessary. Though I
On Mon, Apr 8, 2024 at 12:23 PM Rowan Tommins [IMSoP]
wrote:
>
> As I mentioned in the discussion about a "scalar arbitrary precision
> type", the idea of a scalar in this meaning is a non-trivial challenge, as
> the zval can only store a value that is treated in this way of 64 bits or
> smaller.
On Sun, Apr 7, 2024 at 2:45 PM Rowan Tommins [IMSoP]
wrote:
> On 07/04/2024 20:55, Jordan LeDoux wrote:
>
> > I have been doing small bits of work, research, and investigation into
> > an MPDec or MPFR implementation for years, and I'm likely to continue
> > doing m
On Sun, Apr 7, 2024 at 8:27 AM Rowan Tommins [IMSoP]
wrote:
>
>
> On 7 April 2024 15:38:04 BST, Saki Takamachi wrote:
> >> In other words, looking at how the efforts overlap doesn't have to mean
> abandoning one of them, it can mean finding how one can benefit the other.
> >
> >I agree that the
On Sat, Apr 6, 2024 at 4:07 AM Barney Laurance
wrote:
> Hello,
>
> There are currently two proposals being discussed - *native decimal
> scalar type support* and *Support object type in BCMath*
>
> I've been getting involved in the discussion for the BCMath proposal, but
> not paying as much atte
On Sat, Apr 6, 2024 at 6:45 AM Rowan Tommins [IMSoP]
wrote:
> On 06/04/2024 07:24, Saki Takamachi wrote:
>
> Take a look at the methods shown below:
> ```
> protected static function resultPropertyRules(string $propertyName,
> mixed $value1, mixed $value2): mixed {}
> ```
>
> This method determin
On Fri, Apr 5, 2024 at 1:00 PM Tim Düsterhus wrote:
> Hi
>
> On 4/5/24 21:42, Saki Takamachi wrote:
> > The only solution I can think of at the moment is to impose the
> constraint that
> > when computing operator overloading, if the operands are both objects,
> they must
> > be of the exact same
On Fri, Apr 5, 2024 at 12:42 PM Saki Takamachi wrote:
>
> The only solution I can think of at the moment is to impose the constraint
> that when computing operator overloading, if the operands are both objects,
> they must be of the exact same class.
>
> When calculating using a method, it is cle
On Fri, Apr 5, 2024 at 2:48 AM Tim Düsterhus wrote:
> Hi
>
> Your `Money` example would allow for unsound and/or non-sense behavior,
> such as:
>
> $fiveEuros = new Money(5, 'EUR');
> $tenDollars = new Money(10, 'EUR');
>
> $what = $fiveEuros + $tenDollars;
>
> What would you expec
On Thu, Apr 4, 2024 at 2:19 PM Barney Laurance
wrote:
>
> I don't think it will be possible to make a good Money class as a child of
> this. BcNum is a read-only class, so if the constructor of BcNum is final
> then the child class won't be able to take the currency as a constructor
> param, and
On Thu, Apr 4, 2024 at 2:28 PM Rowan Tommins [IMSoP]
wrote:
>
>
> I haven't followed the discussion in the other thread, but I'm not sure
> what the use case would be for a "fixed scale decimal" that followed
> those rules.
>
> As mentioned before, the use case I've encountered is money
> calcula
On Thu, Apr 4, 2024 at 1:59 PM Barney Laurance
wrote:
> Hi again,
>
> On 27/03/2024 00:40, Saki Takamachi wrote:
>
> Do we also need `toFloat` and `toInt` functions? Seems like using explicit
> functions will be safer than casting.
>
> For toInt I'd expect an exception if the value is outside th
On Wed, Apr 3, 2024 at 7:31 PM Saki Takamachi wrote:
>
> Thanks, I agree with you that it works a little differently than the
> existing BCMath function, so it needs to be well-documented.
>
> I have summarized the discussion so far, made some corrections, and
> updated the RFC. I would be happy
On Mon, Mar 18, 2024 at 1:35 PM Rowan Tommins [IMSoP]
wrote:
>
> Where things get more complicated is with *fixed-precision* decimals,
> which is what is generally wanted for something like money. What is the
> correct result of decimal(1.03, precision: 2) / 2 - decimal(0.515, 3)?
> decimal(0.51,
On Tue, Apr 2, 2024 at 5:43 PM Saki Takamachi wrote:
>
> If make a class final, users will not be able to add arbitrary methods, so
> I think making each method final. Although it is possible to completely
> separate behavior between method and opcode calculations, this is
> inconsistent and conf
On Tue, Apr 2, 2024 at 5:05 PM Jordan LeDoux
wrote:
>
>
> On Tue, Apr 2, 2024 at 4:50 PM Saki Takamachi wrote:
>
>>
>> The two use cases at issue here are when the div and pow's exponent are
>> negative values. So how about allowing only these two method
On Tue, Apr 2, 2024 at 4:50 PM Saki Takamachi wrote:
>
> The two use cases at issue here are when the div and pow's exponent are
> negative values. So how about allowing only these two methods to optionally
> set `$scale` and `$roundMode` ?
>
> - The constructor takes only `$num` and always uses
On Tue, Apr 2, 2024 at 10:24 AM Jordan LeDoux
wrote:
>
>
> On Tue, Apr 2, 2024 at 3:12 AM Lynn wrote:
>
>>
>> I'm inexperienced when it comes to maths and the precision here, but I do
>> have some experience when it comes to what the business I work for wan
On Tue, Apr 2, 2024 at 3:12 AM Lynn wrote:
>
> I'm inexperienced when it comes to maths and the precision here, but I do
> have some experience when it comes to what the business I work for wants.
> I've implemented BCMath in a couple of places where this kind of precision
> is necessary, and I f
On Sat, Mar 30, 2024 at 5:09 PM Saki Takamachi wrote:
> Hi Jordan,
>
> Your opinion may be reasonable given the original BCMath calculation
> order. That is, do you intend code like this?
>
> Signature:
> ```
> // public function __construct(string|int $number)
> // public function getNumber(?int
On Wed, Mar 27, 2024 at 12:08 AM Aleksander Machniak wrote:
> On 27.03.2024 01:03, Saki Takamachi wrote:
> >> $num = new BcNum('1.23', 2);
> >> $result = $num + '1.23456';
> >> $result->value; // '2.46456'
> >> $result->scale; // ??
> >
> > In this case, `$result->scale` will be `'5'`. I added th
On Sun, Mar 17, 2024 at 5:05 PM Saki Takamachi wrote:
> Hi Jordan,
>
> > Using a BCNum inside a loop is the use case, where every loop would
> result in memory allocation for a new object, as well as the overhead of
> the constructor, etc.
> >
> > Granted, only people who REALLY know what they ar
On Sat, Mar 16, 2024 at 8:39 AM Saki Takamachi wrote:
> Hi Barney,
>
> Thanks, that's what I was starting to worry about too. It seems like a
> good idea to support only immutability, as you say earlier in your proposal.
>
> Regards.
>
> Saki
Using a BCNum inside a loop is the use case, where e
On Tue, Feb 6, 2024 at 11:19 AM Arvids Godjuks
wrote:
> On Tue, 6 Feb 2024 at 19:14, Larry Garfield
> wrote:
>
> Thank you Larry for this interesting summary - didn't remember there was
> quite a bit a discussion around the topic prior.
>
> I lean on the "we have exceptions, just leave it be" si
On Mon, Dec 25, 2023 at 8:19 AM Kévin Dunglas wrote:
>
> On Sun, Dec 24, 2023 at 10:44 PM Jordan LeDoux
> wrote:
>
>>
>>
>> On Sat, Dec 23, 2023 at 12:34 PM Kévin Dunglas wrote:
>>
>>> Hello and Merry Christmas!
>>>
>>> One of the
On Sat, Dec 23, 2023 at 12:34 PM Kévin Dunglas wrote:
> Hello and Merry Christmas!
>
> One of the main features of FrankenPHP is its worker mode, which lets you
> keep a PHP application in memory to handle multiple HTTP requests.
>
> Worker modes are becoming increasingly popular in the PHP world
On Fri, Dec 15, 2023 at 12:59 PM Arvids Godjuks
wrote:
>
>
> On Fri, 15 Dec 2023 at 22:32, Jordan LeDoux
> wrote:
>
>> On Fri, Dec 15, 2023 at 12:14 AM Robert Landers > >
>> wrote:
>>
>> >
>> > nobody will likely ever try this again, at
On Fri, Dec 15, 2023 at 12:14 AM Robert Landers
wrote:
>
> nobody will likely ever try this again, at least in the foreseeable
> future. With comments like that, there is simply no way forward.
> There's no convincing (at least via email) and by that point, it's too
> late anyway, they already vo
On Tue, Dec 12, 2023 at 4:29 PM Jordan LeDoux
wrote:
>
>
> On Tue, Dec 12, 2023 at 3:05 PM Erick de Azevedo Lima <
> ericklima.c...@gmail.com> wrote:
>
>> Oh, I just realized that I used the wrong word, so let me rephrase that:
>>
>> What's the name of
On Tue, Dec 12, 2023 at 3:05 PM Erick de Azevedo Lima <
ericklima.c...@gmail.com> wrote:
> Oh, I just realized that I used the wrong word, so let me rephrase that:
>
> What's the name of the library you're talking about? Maybe the *pros* of a
> core implementation can be highlighted if we can see
On Tue, Dec 12, 2023 at 1:26 PM Larry Garfield
wrote:
> On Tue, Dec 12, 2023, at 1:03 PM, G. P. B. wrote:
>
> > The issue is that I don't think having arbitrary precision decimals as a
> > core language feature is a necessity compared to rational types.
> > A cast from rational to float wouldn't
On Tue, Dec 12, 2023 at 1:00 PM Robert Landers
wrote:
>
> Hey Gina,
>
> > GMP supports operator overloading
>
> GMP kinda-sorta-most-of-the-time supports operator overloading.
> Sometimes ... it doesn't. I implemented a field library in PHP (for
> work a couple of years ago) and occasionally, ove
On Wed, Dec 6, 2023 at 10:36 PM Alex Pravdin wrote:
> Hello internals,
>
>
> This is the second round of the discussion regarding arbitrary precision
> scalar type integration into PHP. The previous part:
> https://marc.info/?l=php-internals&m=168250492216838&w=2 was initiated by
> me before deep
On Mon, Oct 23, 2023 at 4:14 AM Saki Takamachi wrote:
> Hi, internals
>
> I would like to start the discussion for my RFC "Change the edge case of
> round()”.
> https://wiki.php.net/rfc/change_the_edge_case_of_round <
> https://wiki.php.net/rfc/adding_bcround_bcfloor_bcceil_to_bcmath>
>
> Regards
On Sat, Oct 28, 2023 at 4:35 PM juan carlos morales <
dev.juan.mora...@gmail.com> wrote:
>
>
> El El sáb, 28 de oct. de 2023 a la(s) 19:25, Jordan LeDoux <
> jordan.led...@gmail.com> escribió:
>
>>
>>
>> On Sat, Oct 28, 2023 at 10:54 AM juan carlos m
On Sat, Oct 28, 2023 at 10:54 AM juan carlos morales <
dev.juan.mora...@gmail.com> wrote:
>
>
> What I mean is more about … migrating a running php instance to another
> node or another php instance, in fact your php code is running, suddenly we
> Need to move to another node, how to do it?
>
Thi
On Mon, Oct 23, 2023 at 10:20 AM Dik Takken wrote:
> On 23-10-2023 18:34, Larry Garfield wrote:
> >
> > Jordan's RFC explained in detail why interfaces are not viable, which is
> why we have to use magic methods (with or without a special keyword)
> instead:
> >
> >
> https://wiki.php.net/rfc/use
On Thu, Oct 19, 2023 at 12:14 AM Pierre wrote:
>
> Maybe I don't master english enough and I can speak to strictly
> sometime. If an operator overload RFC that doesn't have any blind spot
> or weird edge case happens, I'd be happy to see it pass, at least it
> would close bike shedding around thi
On Wed, Oct 18, 2023 at 6:03 AM Pierre wrote:
> Le 18/10/2023 à 14:50, someniatko a écrit :
> > Hi internals,
> >
> > This approach allows combining
> > - no BC break - `~=` is a new syntax which is unavailable in older PHP
> > versions
> > - explicitly showing an intent that objects are compared
On Thu, Oct 12, 2023 at 6:00 PM Lanre Waju wrote:
> It sometimes seems as though certain choices may not align with the best
> interests of the PHP community. I would appreciate it if you could
> provide insights into why this might not be the case.
>
>
To find out why Fibers was done instead of
On Thu, Oct 12, 2023 at 11:32 AM Pierre Joye wrote:
> Hi Jordan
>
> On Fri, Oct 13, 2023, 1:24 AM Jordan LeDoux
> wrote:
>
>>
>>
>> On Thu, Oct 5, 2023 at 5:27 AM Saki Takamachi wrote:
>>
>>> Hi, Pierre
>>>
>>> In fact, I pr
On Wed, Oct 4, 2023 at 5:08 PM wrote:
> Also the poll for increasing from cost 11 to cost 12 should be a 2/3
> majority to get cost 12. Since the poll for increasing from cost 10 to cost
> 11 is a 2/3 majority. You can think of this as a 2/3 majority poll to
> increase to cost 11 followed by a 2/
On Thu, Oct 12, 2023 at 11:24 AM Jordan LeDoux
wrote:
>
>
> On Thu, Oct 5, 2023 at 5:27 AM Saki Takamachi wrote:
>
>> Hi, Pierre
>>
>> In fact, I predict that many use cases will be covered by GMP.
>>
>> Still, I think that there may be cases where c
On Thu, Oct 5, 2023 at 5:27 AM Saki Takamachi wrote:
> Hi, Pierre
>
> In fact, I predict that many use cases will be covered by GMP.
>
> Still, I think that there may be cases where calculation functions like
> mainframe BCD are required, such as when calculating money.
>
> I am unable to decide
On Sun, Sep 3, 2023 at 5:51 AM Alexandru Pătrănescu
wrote:
> Hi!
>
> On Sun, Sep 3, 2023 at 3:14 PM Tim Düsterhus wrote:
>
> >
> > The RFC mentions already has a section with regard to naming:
> >
> > > Why not the names PHP_ROUND_UP and PHP_ROUND_DOWN
> >
> > I generally agree with the argumen
On Fri, Jul 21, 2023 at 3:48 PM Jorg Sowa wrote:
> Thank you for your suggestions. I added two remaining modes and I think
> it's complete now.
>
> I changed the names to `PHP_ROUND_CEILING` and `PHP_ROUND_FLOOR` to be
> consisted with rounding modes in number_format() function. I'm not sure
> ab
On Tue, Jul 18, 2023 at 8:05 AM Robert Landers
wrote:
> On Tue, Jul 18, 2023 at 3:18 PM Olle Härstedt
> wrote:
> >
> > 2023-07-18 14:48 GMT+02:00, someniatko :
> > > I am glad this topic arose! I was also planning to write on this topic
> to
> > > the internals mailing list, but have abandoned t
On Tue, Jan 17, 2023 at 6:28 AM G. P. B. wrote:
> Hello Internals,
>
> I would like to start the discussion on the Path to Saner
> Increment/Decrement operators RFC:
> https://wiki.php.net/rfc/saner-inc-dec-operators
>
> The goal of this RFC is to reduce language complexity by making $v++ behave
On Sat, Nov 26, 2022 at 3:40 PM Deleu wrote:
>
> As I think more about this, there's nothing about the current RFC in this
> code sample. What's breaking LSP here is the child class doing state
> modification, not PHP. To further expand that rationale, PHP allows us to
> create child classes. Wh
On Sat, Nov 5, 2022 at 9:00 AM Tim Düsterhus wrote:
>
> Likewise if you generate a random float between 0 and 1000 with this
> method, some values will appear more often than others due to rounding
> and the changing density of floats for each power of two.
>
> With the γ-section algorithm by Pro
On Wed, Nov 2, 2022 at 1:12 AM Michał Marcin Brzuchalski <
michal.brzuchal...@gmail.com> wrote:
> Hi Josh,
>
> Have you tried not initializing invalid objects? This could help you.
> Also that sounds more logical to me as I don't see any reasons to
> initialize invalid objects if it's a matter of
On Mon, Oct 31, 2022 at 10:43 AM Codito - Grzegorz Korba <
grzegorz.ko...@codito.pl> wrote:
>
> I don't want to edit someone else's RFCs, but I saw there are several
> pages related to the process itself, which I find not as helpful as they
> should be 🙂 I will work on the docs through the PRs, bu
On Mon, Oct 31, 2022 at 12:32 AM Codito - Grzegorz Korba <
grzegorz.ko...@codito.pl> wrote:
> Hi Internals!
>
> I would like to ask for Wiki karma (account: codito) in order to be able to
> edit Wiki pages. I feel like I can help with providing helpful examples or
> improve existing docs. In the f
On Sat, Oct 29, 2022 at 6:02 PM Jordan LeDoux
wrote:
>
>
> On Sat, Oct 29, 2022 at 12:21 PM Jordan LeDoux
> wrote:
>
>>
>>
>>
>> Well... perhaps. But "get bytes from character list" would do exactly
>> what it says it will do, even from
On Sat, Oct 29, 2022 at 12:21 PM Jordan LeDoux
wrote:
>
>
>
> Well... perhaps. But "get bytes from character list" would do exactly what
> it says it will do, even from UTF-8 strings. It will use any of the bytes
> from the character list, even if one characte
On Sat, Oct 29, 2022 at 6:10 AM Claude Pache wrote:
>
>
> > Le 28 oct. 2022 à 23:43, Jordan LeDoux a
> écrit :
> >
> > On Fri, Oct 28, 2022 at 12:30 PM Joshua Rüsweg via internals <
> > internals@lists.php.net> wrote:
> >
> > Not to try and bi
On Fri, Oct 28, 2022 at 12:23 PM Joshua Rüsweg via internals <
internals@lists.php.net> wrote:
> Hi
>
> > You can find the RFC at:
> >
> > https://wiki.php.net/rfc/randomizer_additions
>
> Tim Düsterhus and I have updated the RFC and have broadly adopted the
> proposals.
>
> Firstly we have rename
On Fri, Oct 28, 2022 at 12:30 PM Joshua Rüsweg via internals <
internals@lists.php.net> wrote:
> Hello!
>
> [As Larry kindly pointed out to me, I only sent the email to Larry and
> not to the mailing list.]
>
> > "Alphabet" here still, to me, implies a character set, not a byte
> stream. Maybe ge
On Thu, Oct 20, 2022 at 2:26 PM Pedro Nacht via internals <
internals@lists.php.net> wrote:
> I've made this suggestion as issue #9778 (
> https://github.com/php/php-src/issues/9778) and PR # 9789 (
> https://github.com/php/php-src/pull/9789), but have been invited by
> @damianwadley to bring it t
On Wed, Oct 19, 2022 at 7:37 AM Kamil Tekiela wrote:
> Hi,
>
> I am not sure if we should still support it. But I don't think it's
> unthinkable to expect such feature from PHP. However, personally, I don't
> find pass-by-ref that useful in general. The question is whether this
> feature is used
On Tue, Oct 18, 2022 at 10:22 AM Tim Düsterhus wrote:
>
> This cannot be reasonably done in userland, because you pay an increased
> cost to turn the bytes into numbers and then to perform the necessary
> bit fiddling to debias the numbers.
>
To add to this, I'm going to link to a userland imple
Sorry for double send Nicolas, I hit reply instead of reply-all on my first
message. :)
On Mon, Oct 17, 2022 at 1:57 AM Nicolas Grekas
wrote:
>
> Yes, the specific error message should be part of the BC promise. This
> allows building test suites that can assert the message in a stable way.
> Th
On Tue, Oct 11, 2022 at 6:44 PM David Rodrigues
wrote:
>
> Partially. As the usage definition has not yet been decided between
> private(set) vs. private:set, so this feature is not ready for preview.
> Unless the idea of allowing the two syntaxes to co-exist in this feature is
> acceptable (whic
1 - 100 of 196 matches
Mail list logo
