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
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 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
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 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 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 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 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 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 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 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 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 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: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 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 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 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 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 Sat, Oct 28, 2023 at 10:54 AM juan carlos morales <
[email protected]> 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 Sat, Oct 28, 2023 at 4:35 PM juan carlos morales <
[email protected]> wrote:
>
>
> El El sáb, 28 de oct. de 2023 a la(s) 19:25, Jordan LeDoux <
> [email protected]> escribió:
>
>>
>>
>> On Sat, Oct 28, 2023 at 10:54 AM juan carlos m
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 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 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 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 3:05 PM Erick de Azevedo Lima <
[email protected]> 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 4:29 PM Jordan LeDoux
wrote:
>
>
> On Tue, Dec 12, 2023 at 3:05 PM Erick de Azevedo Lima <
> [email protected]> wrote:
>
>> Oh, I just realized that I used the wrong word, so let me rephrase that:
>>
>> What's the name of
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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
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 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
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 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 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: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 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 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 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 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 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 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 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 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 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 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 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
I'm fairly certain that it is compatible, however I wanted to double check.
Can LGPLv3 sources be included with the PHP source or is the PHP License
incompatible?
Related to the general topic of injection attacks, I was considering
submitting a PR to change the default of PDO::ATTR_EMULUATE_PREPARES to
FALSE, since this mistakenly can lead people to believe that using prepared
statements with PDO and MySQL protects against injection attacks. In fact,
this is
every available tutorial on using PDO in PHP declares that simply using
prepared statements protects you from injection attacks.
On Sun, Jul 18, 2021 at 12:47 AM AllenJB wrote:
>
> On 18/07/2021 03:41, Jordan LeDoux wrote:
> > Related to the general topic of injection attacks, I was
> Are there documented SQL injection opportunities when using emulated
prepares? I'm not aware of any.
This was from my reading of the actual source, which of course may be
flawed. It appeared that if emulated prepares were used the values were
escaped and then passed as strings as part of the que
but
that's why I asked. My intention was not to spread FUD, I just thought I'd
found something that slipped through the cracks.
Cheers,
Jordan
On Mon, Jul 19, 2021 at 12:24 AM Nikita Popov wrote:
> On Sun, Jul 18, 2021 at 4:42 AM Jordan LeDoux
> wrote:
>
>> Relate
On Mon, Jul 19, 2021 at 11:23 PM Andreas Heigl wrote:
> Hey All
>
> Am 19.07.21 um 17:02 schrieb Andreas Heigl:
> > Hey All
> >
> > Am 19.07.21 um 16:34 schrieb Levi Morrison via internals:
> >> On Mon, Jul 19, 2021 at 2:38 AM Nikita Popov
> wrote:
> >>>
> >>> On Sun, Jul 18, 2021 at 8:48 PM Tob
On Mon, Jul 19, 2021 at 11:16 AM G. P. B. wrote:
> On Mon, 19 Jul 2021 at 18:26, Guilliam Xavier
> wrote:
>
> > On Mon, Jul 19, 2021 at 4:26 PM Nicolas Grekas >
> > wrote:
> >
> > >
> > > https://github.com/php/php-src/pull/7259
> > >
> >
> > Great! Thanks! Interesting how it works out-of-the-b
I do not think this is strictly true. The issue that this RFC is running
into is that combination types between intersections and unions was
something that was avoided for the intersection types RFC. Not because the
authors never thought of it, but because the RFC would have become very
broad and e
> - PHP 7.0 types were a pain because of non-nullable types, the feature
only became really useful as of PHP 7.1
See, this keeps being said, but as another userland developer it's
extremely confusing. The types in 7.0 were very useful, and I personally
didn't notice at all that they were missing b
Intersection types are very useful if you use composition over inheritance.
That is, in PHP, they are most useful when you are using multiple
interfaces and/or traits to represent different aspects of an object which
might be present. For example, using an actual library I maintain, I have a
concep
Hey all,
I contacted Jan a few days ago to ask if they were going to try again for
their RFC, but I wanted to get a quick temperature check on this.
I would like to work on this RFC for 8.2, and after going through previous
discussions on the topic, I feel like the right place to start is to limi
mentation. I don't want
to do this quickly and end up with something that gets accepted because we
want some form of operator overloading, or something that gets rejected
again despite putting in a great deal of work.
Jordan
On Sat, Aug 7, 2021 at 12:07 PM Rowan Tommins
wrote:
> On 06/08/2021
On Sat, Aug 7, 2021 at 3:29 PM Larry Garfield
wrote:
>
> Side note: Please remember to bottom-post.
> (trimmed message)
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
Sorry about top-posting. :)
Your
On Sat, Aug 7, 2021 at 8:26 PM Dusk wrote:
> On Aug 7, 2021, at 15:28, Larry Garfield wrote:
> > As an example here, time units. Adding two hour:minute time tuples
> together to get a new time (wrapping at the 24 hour mark) is an entirely
> reasonable thing to do. But multiplication and divisi
On Sat, Aug 7, 2021 at 8:20 PM Mike Schinkel wrote:
> > On Aug 7, 2021, at 10:28 AM, Larry Garfield
> wrote:
> I strongly echo Larry's concern here.
>
> While I tend to be one who wants more language features, not less, the
> availability of unconstrained operator overloading can beckon an
> ine
On Sun, Aug 8, 2021 at 3:08 AM Deleu wrote:
> I started reading this thread with a total bias against it and as I read
> through it I can only imagine how painful and annoying it is to maintain a
> math library in PHP. Operator Overloading is truly a marvelous piece of
> functionality for that do
On Sun, Aug 8, 2021 at 9:52 AM Rowan Tommins
wrote:
>
> Yes, and as I demonstrated, there are situations where some of the
> operators are only meaningful for a subset of operands. Saying that a
> Money object is "Multipliable" would also be "a lie", since multiplying
> two Money objects together
On Mon, Aug 9, 2021 at 3:49 AM Mike Schinkel wrote:
> 1. When you speak of "not documented in the code" do you mean the
> implementation would not be in PHP code? Okay, yet none of these functions
> are documented in PHP code and they are all available in PHP:
>
> https://www.php.net/manual/en/re
On Mon, Aug 9, 2021 at 11:40 AM Peter Cowburn wrote:
> On Mon, 9 Aug 2021 at 18:48, Jordan LeDoux
> wrote:
>
>>
>> You claim that this would be documented on php.net and this would be
>> sufficient. Yet the DateTime class has had operator overloads for
>> c
Apologies, this is being broken into two messages because of the 3
byte limit on the list.
On Mon, Aug 9, 2021 at 2:32 PM Mike Schinkel wrote:
>
> Improving documentation is an easier fix than adding a complex language
> feature. And a key difference is (almost?) anyone who is motivated can
On Mon, Aug 9, 2021 at 2:32 PM Mike Schinkel wrote:
> However, you are actually making my point, which is that since they are so
> deterministic then why is there the need for flexibility to be done in
> userland vs. the standardization that could be could be better in PHP core?
> For the latter
On Tue, Aug 10, 2021 at 12:15 AM Mike Schinkel wrote:
>
> So that gives me two (2) thoughts
>
> 1.) First is Geometry would be another area for PHP to consider adding
> classes.
>
> 2.) Then I thought: What if PHP had the ability to explicitly define
> *value* objects? I know this has been somet
On Tue, Aug 10, 2021 at 8:46 PM Mike Schinkel wrote:
>
> Either way if PHP can identify a value object then it could limit operator
> overloads to just classes that are value objects by whatever approach PHP
> chooses to distinguish.
>
>
> -Mike
> [*] Ironically I mentioned you because I thought
On Wed, Aug 11, 2021 at 1:42 AM Mike Schinkel wrote:
>
> It that what you envision? To create a ComplexNumber() do I first need to
> wrap in Real() and in Imaginary()? Or where you intending I could just
> pass numeric literals? If yes, PhpStorm said your type hints did not allow
> it.
>
>
In t
Hey internals,
I've been working on the draft for my operator overloading RFC, and in
doing so I encountered a separate change that I would like to see.
That is, the use of `never` as an argument type for interfaces. Since
arguments in PHP are contravariant to preserve Liskov substitution, `never
1 - 100 of 196 matches
Mail list logo
