Hi all,
(Cross-posting to PECL and Internals lists, because I'm not sure which
will reach the best audience.)
As you may be aware, PECL contains two extensions for connecting to
memcache: one called "memcache", and one called "memcached". This has
always been a great source of confusion, pa
On further investigation, I'm not sure if we need both `__equals` and
`__compareTo`,
even with all the talk about contexts and the fact that an object can be
tested for
equality and not necessarily ordering as well. If we take out the
`__equals` method
and only include `__compareTo`, we can allow t
What's the best place to override == internally? `do_operation` or a new
object handler?
I'd like to separate equality from compare_function.. or should we ignore
`__equals `
and assume that the values are equal if `__compareTo` returns 0?
Here's some context: I'm modifying `is_equal_function` to
> Yes, that's the type of thing that I think needs to be included as
> part of the RFC.
>
> Including a list of all the (or at least the important) functions that
> would be affected by this RFC should be made both for clarity and so
> that people can think through any edge cases.
Absolutely. I w
On 22 June 2018 at 12:31, Rudi Theunissen wrote:
>
>> I think if you want to push the RFC forward, a really quite strong
>> case needs to be made for why having it be a language level feature is
>> so much better (or even at all better) than having it be implemented
>> in userland.
>
>
> 1. You
>
> In my opinion we should have functions which take comparator and/or
> equality functions as parameters even if we can override these
> operators.
I really like this idea, because it puts the responsibility of the
definition on the caller. It
allows you to do things like "Is there an instance
Hi,
I just created a PR [1] to add two new options for ssl/tls streams:
- min_proto_version
- max_proto_version
that can be set to one of the new constants:
- STREAM_CRYPTO_PROTO_SSLv3
- STREAM_CRYPTO_PROTO_TLSv1_0
- STREAM_CRYPTO_PROTO_TLSv1_1
- STREAM_CRYPTO_PROTO_TLSv1_2
It is basically a ran
On Fri, Jun 22, 2018 at 6:39 AM Levi Morrison wrote:
>
>
> > 1. You can't override the behaviour of `<`, `<=`, `>`, `>=`, `==`, `!=`
> > with a userland implementation.
> > 2. Therefore, you won't be able to affect the internals of array functions
> > like `in_array`, `sort` etc.
>
> In my opinion
> 1. You can't override the behaviour of `<`, `<=`, `>`, `>=`, `==`, `!=`
> with a userland implementation.
> 2. Therefore, you won't be able to affect the internals of array functions
> like `in_array`, `sort` etc.
In my opinion we should have functions which take comparator and/or
equality funct
> If __compareTo($other) gives 0 then there is no justification for
additional method.
> IMO you're duplicating functionality here.
I tried my best to explain that this is not the case. There are perfectly
logical cases where
two values are not equal, but have the same relative ordering. The best
On 11.06.2018 at 07:23, Joe Watkins wrote:
> PHP 7.1.19RC1 is ready for testing and can be downloaded from:
Since php-7.1.19 has already been tagged, shouldn't this be the
announcement for 7.1.19?
--
Christoph M. Becker
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, v
11 matches
Mail list logo
