On Wed, Mar 27, 2019 at 2:30 PM C. Scott Ananian
wrote:
> Continuing this saga: I'm still having performance problems on character
> entity expansion. Here's the baseline code:
> https://github.com/wikimedia/remex-html/blob/master/RemexHtml/Tokenizer/Tokenizer.php#L881
> Of note: the regular
Continuing this saga: I'm still having performance problems on character
entity expansion. Here's the baseline code:
https://github.com/wikimedia/remex-html/blob/master/RemexHtml/Tokenizer/Tokenizer.php#L881
Of note: the regular expression is quite large -- around 26kB -- because it
needs to
On Tue, 26 Mar 2019 at 23:09, Benjamin Morel
wrote:
> Also, may I suggest that these 2 RFCs be merged together?
>
> https://wiki.php.net/rfc/string_to_number_comparison
> https://wiki.php.net/rfc/trailing_whitespace_numerics
>
Although they are complementary, the two RFCs are tackling
> I was certainly not clear enough. I was thinking of basic handling of
numeric values, including arithmetic operations *and* comparison operations.
I would be interested to have a real-life use case of when the current
number comparison capabilities of PHP make more sense than those, borrowed
> Le 27 mars 2019 à 16:14, Benjamin Morel a écrit :
>
>
> Sure, PHP has the huge advantage here to have a dedicated string
> concatenation operator, removing any ambiguity around the + operator. This
> does not mean that we cannot borrow their semantics for string/number
> comparison!
I
> Isn't this the purpose of Nikic's Saner PHP String comparison RFC?
It is, sorry I mixed the discussions here. As I said below, I think that
these RFCs would deserved to be merged.
> Because boths nikic's and Andrea's RFC go hand in hand.
> And probably if both these RFC get accepted a new
> Le 27 mars 2019 à 14:29, Benjamin Morel a écrit :
>
> Thinking about this a bit more, what about following JavaScript semantics? I
> find them really good in this respect:
>
Arithmetic in JavaScript cannot be used reliably (in general) without
converting your data to the proper type,
On Wed, 27 Mar 2019 at 14:30, Benjamin Morel
wrote:
> > It is a well-known feature that you can work with such data without
> previously converting it explicitly to some number type.
>
> I'm not requesting to change this: if you're doing string("3.5") + int(7),
> you should still get
> It is a well-known feature that you can work with such data without
previously converting it explicitly to some number type.
I'm not requesting to change this: if you're doing string("3.5") + int(7),
you should still get float(10.5). What I'm suggesting we change, is
comparison of numbers and
> Le 27 mars 2019 à 00:09, Benjamin Morel a écrit :
>
> - I would also strongly suggest that 2 strings are always compared
> byte-by-byte; IMO it does (*somehow*) make sense that 42 == "42.0", but it
> DOES NOT make sense that "42" == "42.0". (...)
There are many ways to obtain numeric data
10 matches
Mail list logo
