On Tue, 4 Jan 2022 at 03:23, Jordan LeDoux wrote:
>
>
>
> On Mon, Jan 3, 2022 at 4:05 PM Andreas Hennings wrote:
>>
>> To me it is not surprising that an RFC like this would be controversial.
>> We could enter a wonderful new era of value objects with operators,
>> but it is hard to envision
On Mon, Jan 3, 2022 at 4:05 PM Andreas Hennings wrote:
> To me it is not surprising that an RFC like this would be controversial.
> We could enter a wonderful new era of value objects with operators,
> but it is hard to envision that beforehand.
>
> The best might be to find and advertise with
On Mon, 3 Jan 2022 at 22:15, Jordan LeDoux wrote:
>
> On Mon, Jan 3, 2022 at 9:07 AM Pierre wrote:
>
> > I forgot to answer to that, specifically. I'd much more prefer to have
> > an explicit `equals(object $other): bool` (magic or not, really I do not
> > care) single method for equality only,
Hello Jordan,
I have another note about the RFC.
(I am not sure what's the policy, if we should continue _all_
discussion here or go back to the RFC thread. Hope it's ok here.)
OperandPosition::LeftSide
OperandPosition::RightSide
I wonder if this is the best way to model this.
Especially, it
On Mon, Jan 3, 2022 at 9:07 AM Pierre wrote:
> I forgot to answer to that, specifically. I'd much more prefer to have
> an explicit `equals(object $other): bool` (magic or not, really I do not
> care) single method for equality only, that'd be great. In that sense, I
> much preferred specific
On Tue, Jan 4, 2022, 2:17 AM Pierre Joye wrote:
>
>
> On Tue, Jan 4, 2022, 1:35 AM Horváth V. wrote:
>
>> On 2022. 01. 03. 18:17, Christoph M. Becker wrote:
>> > Oh, that would be an issue. We can't use Cygwin builds; MinGW builds
>> > might be okayish, though. ICU ships a VS solution file
On 2022. 01. 03. 20:17, Pierre Joye wrote:
it uses msys for autoconf and co support but actually uses vc?
Exactly.
Unless you have another compiler specified in your Conan profile. You
can see in the _platform method that the dictionary is indexed with
self.settings.os and
On Tue, Jan 4, 2022, 1:35 AM Horváth V. wrote:
> On 2022. 01. 03. 18:17, Christoph M. Becker wrote:
> > Oh, that would be an issue. We can't use Cygwin builds; MinGW builds
> > might be okayish, though. ICU ships a VS solution file
> > (source/allinone/allinone.sln) which works fine. I
On 2022. 01. 03. 18:17, Christoph M. Becker wrote:
> Oh, that would be an issue. We can't use Cygwin builds; MinGW builds
> might be okayish, though. ICU ships a VS solution file
> (source/allinone/allinone.sln) which works fine. I don't know
> whether using that would be okay for Conan.
No
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 Mon, 3 Jan 2022 at 16:00, Marco Pivetta wrote:
>
> Hey Andreas,
>
> On Mon, Jan 3, 2022 at 3:40 PM Andreas Hennings wrote:
>>
>> I imagine that operator overloads can improve DX for these use cases,
>> but at a cost for the overall language.
>>
>> How would you (Marco) see the future of
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 discussions on this RFC and the feature in general, please
> refer to:
>
> -
One question that just occured to me:
Why allow the "public" keyword for visibility, if operators are public
automatically, and "private" and "protected" are not allowed?
Do we plan for private/protected operators in the future?
Shouldn't we eliminate meaningless choice?
On Mon, 3 Jan 2022 at
On 03.01.2022 at 18:03, Horváth V. wrote:
> Thanks for the reply. It's very helpful.
>
> The glib issue is an upstream issue on Windows:
> https://gitlab.gnome.org/GNOME/glib/-/issues/692
Ah, sorry, that shouldn't be a problem (at least for Windows), since we
need *shared* libraries there
On 3 January 2022 16:07:53 GMT, Chase Peeler wrote:
>My mistake, I thought it did get casted. Still, I think you add a lot of
>complexity because you'll need to keep track of whether or not a key was a
>string or not. There is no guarantee that all numeric keys were originally
>a string:
>[ "1"
On 03.01.22 17:12, Larry Garfield wrote:
Also, people keep talking about edge cases. In my experience, "are
these two objects equal" (for some object-specific definition of
equal) is very much *not* an edge case. I may have less use for
overloading % as I don't use advanced math that much, but I
Le 03/01/2022 à 17:12, Larry Garfield a écrit :
Also, people keep talking about edge cases. In my experience, "are these two
objects equal" (for some object-specific definition of equal) is very much *not* an
edge case. I may have less use for overloading % as I don't use advanced math that
Thanks for the reply. It's very helpful.
The glib issue is an upstream issue on Windows:
https://gitlab.gnome.org/GNOME/glib/-/issues/692
ICU's Conan recipe doesn't support some platforms:
Le 03/01/2022 à 17:12, Larry Garfield a écrit :
On Mon, Jan 3, 2022, at 9:52 AM, Pierre wrote:
I personally tend to agree with everything that Marco said. Especially
regarding the fact that it's adding huge complexity to the language
itself for mostly edge cases.
I'd argue there's many much
On 03.01.2022 at 17:29, Horváth V. wrote:
> I have created an issue to track dependencies for PHP:
> https://github.com/conan-io/conan-center-index/issues/8618
>
> Please take a look, verify that all of those are needed and if anyone
> has answers for the few questions I have as sublist items,
I have created an issue to track dependencies for PHP:
https://github.com/conan-io/conan-center-index/issues/8618
Please take a look, verify that all of those are needed and if anyone
has answers for the few questions I have as sublist items, then that
would help greatly as well.
Regards,
On Mon, Jan 3, 2022, at 9:52 AM, Pierre wrote:
> I personally tend to agree with everything that Marco said. Especially
> regarding the fact that it's adding huge complexity to the language
> itself for mostly edge cases.
>
> I'd argue there's many much more valuable features that could be
On Mon, Jan 3, 2022 at 10:48 AM Rowan Tommins
wrote:
> On 3 January 2022 15:41:48 GMT, Chase Peeler
> wrote:
> >But "001" casted to 1 will then get casted back to "1" not "001".
>
> "001" would not be cast to an integer in this context:
> https://3v4l.org/gGFHJ
>
>
My mistake, I thought it did
Le 03/01/2022 à 16:00, Marco Pivetta a écrit :
I'd probably use `$ts1->subtract($ts0)`, which doesn't seem to be that
unreadable, and there is no need to abbreviate it to "diff" either.
Whether it needs to be static methods or instance methods depends on
the wished API design.
What this RFC
On 3 January 2022 15:41:48 GMT, Chase Peeler wrote:
>But "001" casted to 1 will then get casted back to "1" not "001".
"001" would not be cast to an integer in this context: https://3v4l.org/gGFHJ
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To
On Sun, Jan 2, 2022 at 7:05 AM Rowan Tommins
wrote:
> On 2 January 2022 03:47:11 GMT, Kirill Nesmeyanov wrote:
> >
> >I just gave an example of what at the moment can cause an exception in
> any application that is based on the PSR. It is enough to send the header
> "0: Farewell to the server".
Hey Andreas,
On Mon, Jan 3, 2022 at 3:40 PM Andreas Hennings wrote:
> I imagine that operator overloads can improve DX for these use cases,
> but at a cost for the overall language.
>
> How would you (Marco) see the future of arithmetic libraries for time,
> money etc without overloaded
On Mon, 3 Jan 2022 at 02:07, Marco Pivetta wrote:
>
> Hey Jordan,
>
> I've voted "no" on this one: infix functions may have been interesting, but
> adding a whole new type system around operators is really not worth it,
> given:
>
> * Added AST nodes
> * Added method definitions for niche
On Sun, Jan 2, 2022, at 6:13 PM, 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 discussions on this RFC and the feature in general, please
> refer to:
>
> -
> Am 03.01.2022 um 01:13 schrieb Jordan LeDoux :
>
> 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 discussions on this RFC and the feature in general, please
> refer to:
>
> -
30 matches
Mail list logo
