On Fri, Jul 29, 2022 at 7:15 AM mickmackusa wrote:
>
>
> On Monday, July 25, 2022, Guilliam Xavier
> wrote:
>
>> On Sat, Jul 9, 2022 at 1:56 AM mickmackusa wrote:
>>
>>> I've discovered that several native string functions offer a character
>>>
that strtr() is "not a good candidate
because character order matters" (although you give a reasonable example)?
Maybe you have some counter-example?
Regards,
--
Guilliam Xavier
ail, I too like the idea to split `getInt(int $min =
UNKNOWN, int $max = UNKNOWN)` into distinct `nextInt()` and
`getInt(int $min, int $max)` [in a subsequent PR, IIUC].
Regards,
--
Guilliam Xavier
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.
7;t feel like I'm passing "bytes"
(or "a binary") but a string (to be shuffled byte-wise rather than
character-wise or codepoint-wise, but that's from the function, not the
argument)...
Granted, not compelling, and probably won't matter in practice, but hey ;)
Regards
PS: sent from mobile
--
Guilliam Xavier
> > https://wiki.php.net/rfc/random_extension_improvement
>
> Hi Internals.
>
> Currently, the renaming of Randomizer::shuffleString() to
> Randomizer::shuffleBytes() seems acceptable.
>
> I forgot to note the change regarding arguments when I submitted this RFC.
> With this change, the argument wa
On Thu, Jun 30, 2022 at 7:37 PM Arnaud Le Blanc wrote:
>
> On jeudi 30 juin 2022 18:29:44 CEST Guilliam Xavier wrote:
> > Ah? Sorry, I had interpreted
> > https://github.com/php/php-src/pull/8330/files#diff-85701127596aca0e597bd796
> > 1b5d59cdde4f6bb3e2a109a22be859
OL;
```
with current output (https://3v4l.org/ve3BL#v8.1.7):
```
- unsetting $x
- calling $fn
int(65)
- unsetting $fn
destructed
- DONE.
```
where the optimization would make the "destructed" line move up to
just after "- unsetting $x"
--
Guilliam Xavier
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
://3v4l.org/99XUN#v8.1.7 that he just sent,
> modified to not capture the $some_resource and you can see that it is
> indeed released earlier than if it were captured.
And here it is "un-modified": https://3v4l.org/gZai2 where you see
that calling $fn() (which internally nullifies *its local copy of*
$some_resource) does *not* release; is it really what you expect? are
you creating the closure only to extend the lifetime of
$some_resource?
Regards,
--
Guilliam Xavier
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ver be incremented and thus
> fail to work as defined.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
No offense, but why don't you just try it? Please see equivalents of:
- Dan's code: https://3v4l.org/51jXY => doesn't "work"
- Dan's code with capture by reference (as said by Rowan):
https://3v4l.org/JoUVi => "works"
- Rowan's code: https://3v4l.org/7ZVv3 => shows the "problem" with capture
PS: I see that Rowan just replied with refcount explanations. I agree
(but am sending this anyway)
Regards,
--
Guilliam Xavier
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
itance (and
reflection), and what exactly should happen when a function throws an
exception it didn't "declare"...
PS: I also found some old feature requests:
- https://externals.io/message/4424
- https://bugs.php.net/bug.php?id=42251
- https://bugs.php.net/bug.php?id=62404
ere
(first, it makes sense that pickArrayKeys has `int $num` *without* a
default value [even if array_rand has 1]; second, "pickArrayKey" [if
really wanted] is trivial to implement in userland as a wrapper around
pickArrayKeys [but the opposite would not be so], and I don't think
that adding *both* methods to Randomizer is desirable either [better
keep it simple/minimal]).
Regards,
--
Guilliam Xavier
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
lternative design would be `Randomizer::pickArrayKey(array
$array): int|string`, but migrating existing uses with $num != 1 would
be harder, so probably not better.
Regards,
--
Guilliam Xavier
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
nts-on-primitive-data-types
(mainly integer ranges, but the concept of "domains" looks similar)
Regards,
--
Guilliam Xavier
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
y to hear it.
Sorry I don't have better ideas... Maybe others will?
--
Guilliam Xavier
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
but what about
`takes_string(IntEnum::CASE)`, and
`takes_Stringable(StringEnum::CASE)`?
In any case, several people requested that it should require to be
*opted-in* explicitly; but then [for solutions other than "allowing
user-land to implement Stringable"] we probably also need a way to
te
happened after the vote had started (as often,
sadly): https://externals.io/message/102562
--
Guilliam Xavier
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On Mon, Jun 20, 2022 at 5:25 PM Christoph M. Becker wrote:
>
> On 20.06.2022 at 16:44, Go Kudo wrote:
>
> > 2022年6月20日(月) 23:37 Lynn :
> >
> >> On Mon, Jun 20, 2022 at 3:15 PM Guilliam Xavier >> wrote:
> >>
> >>>> https://wiki.php.net/r
t;Always PascalCase") --
excerpts:
| Abbreviations start with a capital letter followed by lowercase
letters, whereas acronyms and initialisms are written according to
their standard notation.
| Good:
| 'CurlResponse'
| 'HTTPStatusCode'
| Bad:
| 'curl_respons
On Fri, Jun 17, 2022 at 7:21 PM Tim Düsterhus wrote:
>
> Hi
>
> On 6/17/22 18:06, Guilliam Xavier wrote:
> >> https://github.com/php/php-src/pull/8819
> >
> > Just so that it can't be said that it hasn't been asked: what about
> > iterator_coun
>https://github.com/php/php-src/pull/8819
Just so that it can't be said that it hasn't been asked: what about
iterator_count(), and iterator_apply()?
Regards,
--
Guilliam Xavier
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
row* functions? e.g.
$fn = fn () use (&$ref) => $ref = $val1 + $val2; // assigns and returns
Would that be allowed? Is it really *desirable*?
Regards,
--
Guilliam Xavier
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
e something like "please don't
add more things encouraging the use of PHP as a templating engine
(unsafe etc.)", but the main target is *non*-HTML (e.g. Markdown or
raw text) templates.
--
Guilliam Xavier
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
t;whitespace
control" options
(https://twig.symfony.com/doc/3.x/templates.html#whitespace-control).
For PHP, if we could ignore BC, I would rather have ?> not eat
newline, and add an optional way to do it; but we can't, so I guess
the opposite (e.g. your =?>) is the best we could hope for.
Re
ing constructors are a terrible idea", and same can be
said for "side-effecting [magic] getters"...
Also note that this only concerns *global* (or namespace-scoped)
constants (which can also be defined "dynamically" with `define()`),
not *class* constants.
--
Guilliam
eal cause of bugs. I often advocate for string
> columns in databases to allow either null or empty string, but not both
> (by adding a check constraint), so that such bugs are caught earlier.
Same (sometimes you have no choice but allow NULL, e.g. an optional
foreign key, but the referenced
oth the
check and the call, but that could also degrade DX (IDE
autocompletion, static analysis) especially if calling with
arguments...
(the other parts of your message have been answered by Juliette)
Regards,
--
Guilliam Xavier
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
x27;` (possibly hiding undefined)
and `(string)expr` / `strval(expr)` (potentially casting "too much"
without errors), I've already seen custom functions like
function null_to_empty_string(?string $string_or_null): string
{ return $string_or_null === null ? '' : $string_or_null; }
(but also its "opposite" empty_string_to_null(string $string): ?string)
Regards,
--
Guilliam Xavier
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ype declarations*, and the
"Unaffected PHP Functionality" section could also mention implicit
boolean evaluation in `if`, ternary conditional (?:) and logical
operators (!, &&, ||, and, or, xor)?
Regards,
--
Guilliam Xavier
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
t;Java", it has nothing to do; Java type declaration `Foo`
(where Foo is a class/interface) is equivalent to PHP `?Foo` (or
`Foo|null`) i.e. implicit *nullability* (that you cannot even opt-out;
the `@NonNull` annotation only works with SCA/IDE or AOP), the RFC
discussed here is about implicit *coercion of null to scalar*.
Regards,
--
Guilliam Xavier
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
symfony/blob/c70be0957a11fd8b7aa687d6173e76724068daa4/src/Symfony/Component/HttpFoundation/File/UploadedFile.php#L210-L246
Just not sure whether it should be e.g. `ini_get_size($option)` (like
ini_get) or rather e.g. `ini_parse_size($value)` (more generally
usable).
Regards,
--
Guilliam Xavier
--
P
On Mon, May 2, 2022 at 1:57 PM Alexandru Pătrănescu wrote:
> On Mon, May 2, 2022 at 2:15 PM Guilliam Xavier
> wrote:
>> I too would rather have "extra" deprecation notices in 8.2 than
>> *sudden errors / silent behavior changes* in 9.0 (for the callable
>>
ree with you here: Code which silently changes behavior is also a
> migration hassle.
Hi,
I too would rather have "extra" deprecation notices in 8.2 than
*sudden errors / silent behavior changes* in 9.0 (for the callable
type declaration / the is_callable() function)...
Regards,
--
Guilliam Xavier
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ssignment (VS the comparison)!
Only allowing the following values would make sense
> from my perspective:
>
> '1' => true
> 1 => true
> 1.0 => true
> '' => false
> '0' => false
> 0 => false
> 0.0 => false
>
Seems a reasonable compromise (between BC and bugs-protection).
Regards,
--
Guilliam Xavier
functions.stub.php#L1558
function mt_rand(int $min = UNKNOWN, int $max = UNKNOWN): int {}
documented with two signatures at
https://www.php.net/manual/en/function.mt-rand.php
mt_rand(): int
mt_rand(int $min, int $max): int
--
Guilliam Xavier
uninitialized"
> state, and we're proposing to make reading an unset property an error,
> it would make more sense for it to show as '["untyped":"Foo":private] =>
> uninitialized(mixed)'
>
Understood (also https://3v4l.org/DgXJl ). Maybe start a new thread? (this
one is not shown on externals.io, only findable via search)
--
Guilliam Xavier
On Mon, Apr 25, 2022 at 1:05 PM Craig Francis
wrote:
> On 22 Apr 2022, at 13:09, Guilliam Xavier
> wrote:
>
> > https://wiki.php.net/rfc/mysqli_execute_query
>
> Thanks. Maybe add (or even start with) an example of mysqli_query(), to
> show how "migrating to safe
n't think LOCK_SH = 1 can be changed, but] maybe
FILE_USE_INCLUDE_PATH can be changed to e.g. 32, along with your suggestion
2 (change argument #2 [of file_get_contents()] from `bool $use_include_path
= false` to `int|bool $flags = 0` [*but*] treating `true` like
FILE_USE_INCLUDE_PATH [*rather than 1 i.e. LOCK_SH*] [note sure about
LOCK_NB though])?
(PS: there's also **file()**, which currently supports
FILE_USE_INCLUDE_PATH, FILE_IGNORE_NEW_LINES and FILE_SKIP_EMPTY_LINES...)
Regards,
--
Guilliam Xavier
;s explained in
https://wiki.php.net/rfc/typed_properties_v2#uninitialized_and_unset_properties
*. What's the issue?
* "If a typed property is `unset()`, then it returns to the uninitialized
state. While we would love to remove support for the unsetting of
properties, this functionality is currently used for lazy initialization by
Doctrine, in combination with the functionality described in the following
section."
Regards,
--
Guilliam Xavier
HERE name LIKE %s AND type IN (%s, %s)";
/* ... */
$sql_raw = vsprintf($sql_format, array_map(fn ($s) => "'" .
$db->real_escape_string($s) . "'", [$name, $type1, $type2]));
foreach ($db->query($sql_raw) as $row) {
print_r($row);
}
```
Regards,
--
Guilliam Xavier
ThatMayNotExist and/or $array[?'keyThatMayNotExist']
(call it e.g. "*lenient* property/array access"?) (JS is lenient by default)
But let's not deviate further.
Regards,
--
Guilliam Xavier
r (use
`bool`) should be its own subsection, as that's not exactly "redundancy",
and differs from `array|\Traversable` being interchangeable with `iterable`.
Regards,
--
Guilliam Xavier
ser-defined and internal functions consistent*.", which (to
me) implies *not only* reverting the 8.1 deprecation on internal functions
*but also* "changing user-defined functions under strict_types=0 to
[coerce] null for scalar type[ declaration]s" indeed.
In any case, that should be written clear in the RFC (either in "Proposal"
or "Open Issues").
Regards,
--
Guilliam Xavier
dding them to the properties hashmap through direct assignment, or
by having them assigned by an internal function such as json_decode."
`$obj->prop` alone doesn't define the property "prop", but `$obj->prop =
whatever` does.
Regards,
--
Guilliam Xavier
r handle undefined
properties *on stdClass* together with undefined *array keys*?
(the reasoning could even be extended to classes annotated with the
`#[AllowDynamicProperties]` attribute...)
Regards,
--
Guilliam Xavier
al RFC [https://wiki.php.net/rfc/null-standalone-type]
only proposed standalone `null`, not `false`, so didn't allow `?false`)
but now looking at the implementation, I don't like the special casing.
Regards,
--
Guilliam Xavier
in option
3": both occurrences of "braces" here should be "parentheses" (or "round
brackets", VS "curly brackets")
Best,
--
Guilliam Xavier
> Ah yes, I hadn't considered expanding this RFC to namespaced and global
> constants. Let me mull over implementation syntax for those and include
> them in the RFC. My initial reaction is to not include those in this RFC,
> keeping the scope to just class constants. If there is value in typing
>
d that could even be an opportunity to rewrite it in a more
"functional" style...)
Regards,
--
Guilliam Xavier
of type `Fruit` (ultimately `object`),
not `string`. But it is *not* mutable, and *is* allowed as a const value
currently.
Besides, I realized that the RFC is [only] for *class* constants; what
about *namespaced (and global)* constants?
Regards,
--
Guilliam Xavier
ith a function call like
`"...{foo($bar)}..."`, and also with complex interpolation via callable
variable like `"...{$foo($bar + baz($qux))}..."` but not with simple
constant like `"...{FOO}..."` or operation like `"...{$foo + 1}..."` :/
Regards,
--
Guilliam Xavier
e good
> practical example!). At this point I'm going to work on a new RFC with all
> the details and feedback from this discussion.
>
>
Thanks & good luck! =)
--
Guilliam Xavier
> I intentionally left `abstract` out of `public const bool CAN_FLY;` in the
> `abstract class` for consistency with the implementation with `interface`,
> which would also have to be `public const bool CAN_FLY;`. Currently
> `abstract` is only used in front of methods `abstract function doThing():
ed" too (and used abstract static methods where the
implementations just return a literal value...).
Just 2 remarks: in abstract class Bird, shouldn't it be:
- "*abstract* public const bool CAN_FLY;" (and same for FAMILY)
- "return *static*::CAN_FLY;"
?
Regards,
--
Guilliam Xavier
Hi Mike, Lynn, and Kamil; I feel like this sub-thread has derailed from the
initial topic... As already said, this RFC is *not* about the general
"variable variables" feature, but about *the `"${...}"` syntax inside
interpolated strings* (i.e. double-quoted or heredoc), which can be
rewritten to ei
wards 1 for userland functions
(esp. in implications of BC impact)?
Regards,
--
Guilliam Xavier
Hi again,
FWIW, Dan's and Claude's explanations (thanks!) and arguments made me
change my preference to option 1 (i.e. make SensitiveParameterValue not
serializable, period).
Best regards,
--
Guilliam Xavier
t;
> [1] https://wiki.php.net/rfc/redact_parameters_in_back_traces
>
Hi Tim,
I would prefer option 2 (if possible), to avoid potentially breaking
existing code.
Calls to ->getValue() will be in new code written specifically for
SensitiveParameterValue anyway, and can be wrapped into try-catch, I think?
Best regards,
--
Guilliam Xavier
e it is: https://externals.io/message/116188
(+1 for me, with or without false)
Regards,
--
Guilliam Xavier
fined as it would not change
> anymore in PHP 9.
>
Or maybe (if going directly from error to implicit coercion is deemed too
"risky") the current TypeError in non-strict_types mode (when passing NULL
to a user-defined function expecting a scalar) could first be "demoted" to
some kind of Notice [who said E_STRICT] in 8.2 (along with reverting the
Deprecation added in 8.1 for internal functions) and removed in 9.0?
--
Guilliam Xavier
On Tue, Feb 15, 2022 at 3:07 PM Rowan Tommins
wrote:
> On 15/02/2022 12:54, Andreas Leathley wrote:
> > The problem with your way of writing code is that it is ambiguous in
> > meaning, which is why this is a warning.
>
>
> I think that's a good way of looking at it. There's actually quite a lot
nting operator == allows using in_array to find an object in
> an array?
> Which of these internal functions use == and which use ===, which is not
> overloadable?
> Does implementing operator <=> allows sorting of arrays containing my
> objects?
>
> Côme
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
I too would be interested in your answers to those.
Best regards,
--
Guilliam Xavier
s the same as "string".
https://3v4l.org/rlZFF#v8.1rc3
Still surprising... maybe possibly useful for dynamically generated code? :/
--
Guilliam Xavier
>
> For example, this is valid:
>
> echo "string"::class;
>
What! Why is it allowed when it gives the same as string::class, and
$string::class is an error? https://3v4l.org/hfvXm#v8.1rc3
--
Guilliam Xavier
On Wed, Oct 13, 2021 at 11:17 AM Guilliam Xavier
wrote:
> Off-topic:
>
> if ( class_exists('\\WeakMap') ) {
>>
>
> People should stop using a leading slash in FQCN *strings*. \Foo::class
> is "Foo", not "\Foo". It might work generally
Off-topic:
if ( class_exists('\\WeakMap') ) {
>
People should stop using a leading slash in FQCN *strings*. \Foo::class is
"Foo", not "\Foo". It might work generally but that's asking for problems
(e.g. for autoloaders).
(Sorry.)
d a flag (I think?)...
PS: and array_column() has the opposite issue...
--
Guilliam Xavier
Yes please! This has been requested multiple times, for instance:
- https://bugs.php.net/bug.php?id=64493
- https://bugs.php.net/bug.php?id=66435
- https://bugs.php.net/bug.php?id=73735
Regards,
--
Guilliam Xavier
days but it
> also doesn't fail which seems wrong to me.
>
> I don't have much knowledge about internals but would it be possible to
> define "public readonly int|false $days" not using getters/setters and
> keep all other properties as it?
>
Hi,
FWIW, I too agree that [$interval->days, $interval->days = 2,
$interval->days] giving [0, 2, 0] without any warning (or
https://3v4l.org/h8Cju for a variation) seems wrong.
Regards,
--
Guilliam Xavier
parameter `array|object
$data` becoming `string $query` and the return type `string` becoming
`array`, of course);
- do not do name mangling (and for your question "what should happen to
mismatched square brackets?": not sure without an example, but I would say
"just keep them as is").
Best regards,
--
Guilliam Xavier
ot;)?
- "Should brackets around the intersection be: not needed / mandatory /
allow both styles": maybe clearer would be e.g. "forbidden / mandatory /
optional (allow both styles)"?
Regards,
--
Guilliam Xavier
Replying to multiple things:
On Mon, Jul 19, 2021 at 8:16 PM G. P. B. wrote:
>
> And I find it frankly insulting that in the four month this RFC has been
> published for discussion, with multiple push backs for voting due to bugs
> and me wanting that people know what implementation is - for the
not be considered usable
> by some projects, but the feature freeze is today.
>
Which can also be reversed: "The feature freeze is today, but this
limitation might make intersection types not be considered usable by some
projects"? (playing devil's advocate, I don't master the process)
Regards,
--
Guilliam Xavier
P 5, and] we got scalar type declarations and return type
declarations in 7.0 but nullable type declarations "only" in 7.1 (but I
agree).
--
Guilliam Xavier
ot;special", and
that PHP has a history of "nullability" being more than "just a union where
one of the types is `null`", making "nullable intersection types" desirable
(even without waiting for [hypothetical] full composite types). But I fear
that most of the previous points still apply...
> Another argument is that ?A&B might collide with a future syntax. But I
> fail to see how. For sure we create examples of such collisions, but they
> all look constructed to me.
>
> Shouldn't we allow ?A&B ? Intersection types look unfinished to me without
> compat with nullables.
>
> Cheers,
> Nicolas
>
--
Guilliam Xavier
t with the other lines (which all use
> $wpdb->prepare).
>
I don't think so. Looking at
https://developer.wordpress.org/reference/functions/sanitize_text_field/ and
https://developer.wordpress.org/reference/classes/wpdb/esc_like/
you can see that they *don't* escape single quotes,
so there was *indeed* an SQL injection vulnerability in that code.
(Which is [one of the reasons] why I avoid WordPress [and especially
third-party themes / plugins] as much as possible.)
--
Guilliam Xavier
ts.php#errorfunc.constants.errorlevels.e-deprecated-error
(*emphasis* mine)
E_DEPRECATED: Run-time notices. Enable this to receive warnings about
code that *will not work in future versions*.
As for "significant BC breakage", isn't that what major versions are for?
(and with the current release plan, 9.0 would be for end 2025, i.e. 4 years
after 8.1)
Regards,
--
Guilliam Xavier
with nowdoc [VS heredoc].)
As for the proposal, overall I agree with Rowan -- well, that would not be
exactly like single quotes (regarding [not] escaping them), but still "yet
another way" to write a nowdoc string literal.
PS: "amusingly", the code samples are hard to understand
On Tue, Jun 29, 2021 at 10:32 PM Levi Morrison via internals <
internals@lists.php.net> wrote:
> On Tue, Jun 29, 2021 at 12:05 PM Larry Garfield
> wrote:
> >
> > On Tue, Jun 29, 2021, at 1:00 PM, Larry Garfield wrote:
> > > On Tue, Jun 29, 2021, a
r brought up in the discussion.
>
> Finally found where I read that, it’s in an other RFC:
>
> https://wiki.php.net/rfc/first_class_callable_syntax#partial_function_application
>
For the record, Larry replied on this subject:
https://externals.io/message/114770#114785 (second part).
Note that for `$$->foo(/*whatever*/)` the signature couldn't be extracted
(because the class of $$ is unknown).
Regards,
--
Guilliam Xavier
at a different syntax (e.g. with a prefix operator)
would result in a simpler implementation?
Regards,
--
Guilliam Xavier
characters from left, or take the
> leftmost part of the string.
>
True, I can also imagine bikeshed like "str_leftmost", "str_start",
"str_first[_n]" (and same for rightmost/end/last)...
> Don't take it the wrong way, but I think it's a waste of time to implement
> a function that doesn't even need a polyfill in the userland.
>
> Regards,
> Kamil
>
--
Guilliam Xavier
k basically the same [with different names] a few days ago
("why can't we have both?"), but then remembered
https://externals.io/message/114835#114951 , esp. the end:
"""
And to support having 2 functions, we would need 2 flags on strings. These
flags are limited,
ply: thank you for writing the polyfills
clear =)
Regards,
--
Guilliam Xavier
ht! Just to complete: there's also
iconv_substr() (but with the same result as mb_substr()), and here are two
links to compare: https://3v4l.org/kU9D5 vs https://3v4l.org/pAvB0
Regards,
--
Guilliam Xavier
t at clouds).
>
> Am I misunderstanding what these proposed functions should do, or am I
> underestimating the difficulty of typing a zero or negative sign on certain
> keyboards?
>
I think that's more about "semantics" ("conveying intent to readers") than
typing...
That said, I tend to agree with George (but maybe I'm "too" used to seeing
substr()?)
Regards,
--
Guilliam Xavier
Meanwhile, if anybody knows why the RFC isn't listed on `/rfc`, lemme know
> :D
>
You have to add it manually, cf https://wiki.php.net/rfc/howto 3.4
(yeah...)
Cheers
--
Guilliam Xavier
ould be
a one-liner `implode(array_map(fn ($c) =>
['0','1','2','3','4','5','6','7','8','9','-'=>'-'][$c],
str_split((string)$int)))`), so that those `implode(',', [1,2,3])` could
use `implode(',', array_map('to_literal', [1,2,3]))`?
Regards,
--
Guilliam Xavier
d its current
> minimalism.
>
Before going to vote, I think the RFC should be updated to at least mention
the strict-VS-loose comparison choice (for things like `match {
preg_match(/*...*/) => /*...*/ }`).
Regards,
--
Guilliam Xavier
ROM foo LIMIT ' . (int)$limit` even if $limit doesn't come from
a "static" value (e.g. random_int() or even `$_GET['limit']`)
--
Guilliam Xavier
`$shuffledList =
$random->shuffleArray($list);` etc.
I think this is well-consistent with the "pure design" described by Nikita,
and I personally find it both flexible/extensible and easy-to-use =)
(Just beware that the namespace question will probably pop up again.)
PS: I feel like my numerous questions/suggestions (in this thread and the
previous ones) may also have caused some deviations, so I hope that I won't
need more and that other participants will reach a consensus...
Best regards,
--
Guilliam Xavier
ected" Error,
and `$boo = $baz(...);` makes the subsequent `$boo(5);` throw a "not enough
arguments ..." Error)
(weird, looks like `$bar = $foo(2, ...);` and/or `$baz = $bar(3, ...);`
dropped too many params)
Regards,
--
Guilliam Xavier
On Thu, Jun 10, 2021 at 7:32 PM Guilliam Xavier
wrote:
>
> Since `$null?->whatever(1, 'a')` currently always returns null without
> error, shouldn't `$null?->whatever(?, 'a')` return a closure (with a
> signature built from the placeholders onl
On Thu, Jun 10, 2021 at 4:34 PM Larry Garfield
wrote:
> On Thu, Jun 10, 2021, at 3:17 AM, Guilliam Xavier wrote:
> > On Wed, Jun 2, 2021 at 7:47 PM Larry Garfield
> > wrote:
> >
> > > https://wiki.php.net/rfc/partial_function_application
> >
> >
ped parameter `?Foo $foo`)?
Related, for `$null === null`, is `$c = $null->bar(?);` / `$c =
$null::baz(?);` an immediate error, or only later when calling `$c($arg)`?
Regards,
--
Guilliam Xavier
ior
when calling nextInt() in a 32-bit environment using a 64-bit RNG [...]
which means that the code loses compatibility with the result of running on
a 64-bit machine"? And you asked if throwing an exception would be
preferable?
Anyway, I personally don't care about 32-bit (but other people may).
> Regards,
> Go Kudo
>
Regards,
--
Guilliam Xavier
>
> Couldn't the Random class simply implement `public function __clone():
> void` (that would internally do like `$this->algo = clone $this->algo;`)?
>
Sorry I meant like `$this->rng = clone $this->rng;`.
PS: Please don't reply to this erratum, but rather to the previous message
;)
gt;
> > Therefore, an equivalent method to mt_getrandmax() is no longer provided.
>
Great!
> >
> > > uint64 & right-shift
> >
> > This is a specification of the RNG implementation. PHP does not have
> > unsigned integers, but RNG handles unsigned integers (to be precise, even
> > the sign bit is random).
> >
> > As mentioned above, PHP does not have unsigned integers, which means that
> > using the results generated by RNGs may cause compatibility problems in
> the
> > future. To avoid this, a 1-bit right shift is always required (similar to
> > mt_rand()).
>
Good to know, thanks.
Regards,
--
Guilliam Xavier
On Tue, Jun 8, 2021 at 4:09 PM Larry Garfield
wrote:
> On Tue, Jun 8, 2021, at 5:41 AM, Guilliam Xavier wrote:
>
> > you forgot to update one
> > `explode(?)` to `str_split(?)`, and also, the first `fn($v) =>
> > 'strtoupper'` should be just `'strtoupp
Name() as a step, something not possible with
PFA), and is also trivially free. A PFA-based optimization would entail
significant overhead relative to simple function calls, unless special
optimization for the pipe operator usage is introduced (which may not be
possible, depending on precise semantics).
"""
Could you (or Nikita) expand a bit on this (esp. the advantages of the PFA
approach / disadvantages of Hack's approach)?
Regards,
--
Guilliam Xavier
T)
);
That said, I wouldn't mind a new indent parameter (but note that allowing
an arbitrary string [not limited to whitespace] might result in invalid
JSON).
Regards,
--
Guilliam Xavier
1 - 100 of 190 matches
Mail list logo
