take any action based on speculation.
Regards,
Rowan Tommins
[IMSoP]
first version works because the fn() closure captures $data
by-value, effectively cloning it.]
Regards,
--
Rowan Tommins
[IMSoP]
e
correct "disposal" of an object rather than hooking entry to and exit from a
"context":
https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/statements/using
Regards,
--
Rowan Tommins
[IMSoP]
guage integrations", but that
didn't carry across when they rewrote it last summer:
http://web.archive.org/web/20230608040408/https://docs.wasmer.io/ They
may be intending to come back to it later, but at the moment it seems
they are not dedicating any resources to it.
Regards,
--
Rowan Tommins
[IMSoP]
u can upload native binaries already) on the other.
Regards,
--
Rowan Tommins
[IMSoP]
at an RFC could realistically propose right now. So I
say again, to those of you interested in the topic: contribute to the projects
already building the extensions, that's where the next steps are, not here.
Regards,
Rowan Tommins
[IMSoP]
projects like extism develop, making use of those runtimes to run alongside
other languages. But as far as PHP, or Python, or Java, is concerned, those
runtimes are an external process or library that is being interfaced.
Integrating with them is no different, in principle, from integrating the
driver for some new kind of database.
Which is great; it means you don't need any approval from this list, or to
write up an RFC, you can get involved in building that integration right now,
wherever people are working on an extension to enable it.
Regards,
Rowan Tommins
[IMSoP]
VM - like running Scala and Java code in the same JVM; or Hack and
PHP in (older versions of) HHVM.
Regards,
--
Rowan Tommins
[IMSoP]
that the *resolution* of PHP's operators aren't
currently determined by their left-hand side, e.g. int + float and float + int
both return a float, which certainly feels like "preferring the float
implementation regardless of order", even if PHP doesn't technically implement
it that way.
Regards,
--
Rowan Tommins
[IMSoP]
re, and it seemed beneficial to move it into the php-src repository rather
than releasing it separately.
Regards,
--
Rowan Tommins
[IMSoP]
eed as current PHP.
This is where gathering a good catalogue of use cases would come in
handy: which of them would be impossible, or annoyingly difficult, with
a more restrictive resolution method?
Regards,
--
Rowan Tommins
[IMSoP]
rgument was something like
`$isReversed` or `$left` or so on is somewhat ambiguous, while the
enum makes it extremely explicit.
Ah, fair enough. Explicitness vs conciseness is always a trade-off. My
thinking was that the "reversed" form would be far more rarely called
than the "normal" form; but that depends a lot on which resolution
algorithm is used.
Regards,
--
Rowan Tommins
[IMSoP]
, even though it's on the RHS. (I spotted this
in the Python docs, and it seems very sensible.)
Finally, a very quick note on the OperandPosition enum: I think just a
"bool $isReversed" would be fine - the "natural" expansion of "$a+$b" is
"$a->operator+($b, false)"; the "fallback" is "$b->operator+($a, true)"
Regards,
--
Rowan Tommins
[IMSoP]
necessary* to build extensions, by adding to the core language the things you
currently need extensions to do. Things like efficient string buffers and
binary stream manipulation, or attributes and magic methods to override object
behaviour.
Regards,
Rowan Tommins
[IMSoP]
here.
I mean, like Phalcon plans to, ship both a binary extension and a PHP library,
putting only certain essential functionality in the extension. It's how MongoDB
ships their PHP bindings, for instance - the extension provides low-level
protocol support which is not intended for every day use; the library is then
free to evolve the user-facing parts more freely.
Regards,
Rowan Tommins
[IMSoP]
we
should be aiming to reduce the difference between what can be done in
extensions and what in PHP code, rather than planning any new such differences.
Regards,
Rowan Tommins
[IMSoP]
es; the aim of the
vote is to confirm that a conclusion and a consensus has been reached.
Regards,
Rowan Tommins
[IMSoP]
e's no on-going cost.
Obviously, at some point the redirects might get accidentally broken,
but they would also be easy to put back if somebody noticed.
--
Rowan Tommins
[IMSoP]
nctuation-heavy, and I think that's a valid
style which we should keep to.
--
Rowan Tommins
[IMSoP]
a name where a reference number was expected, or a size in pixels where a
size in centimetres was expected). That use is compromised if every scalar
value is silently accepted for any matching typedef.
Regards,
Rowan Tommins
[IMSoP]
ew features tend to tune out.
I will now try to practice what I preach, and not post further in this thread
unless it moves onto something more concrete.
Regards,
--
Rowan Tommins
[IMSoP]
t, which has also come up in the past.
The big challenge in all of them is that these are big fundamental language
changes, which require an expert knowledge of how the language works under the
hood to get much beyond "that would be nice to have". Let's not get too deep
into discussing the colour of the bikeshed before we've worked out if there's
space to build one.
Regards,
Rowan Tommins
[IMSoP]
on
a class definition, and `if this RFC passes, it would automatically apply to
json_encode() as well as serialize().
Regards,
--
Rowan Tommins
[IMSoP]
viously, the language cannot directly control the compatibility promises of
third party libraries, but these principles are well enough known that I would
expect popular projects to base their versioning / deprecation policies on them.
Regards,
Rowan Tommins
[IMSoP]
ble, but I have assumed the RFC will continue to advocate for
option 1 (allow any expression and assume problems will be rare).
I hope I have explained it clearly enough this time to overcome the
previous misunderstandings of where the issue lies.
Regards,
--
Rowan Tommins
[IMSoP]
proposed direction: this section
https://wiki.php.net/rfc/named_params#parameter_name_changes_during_inheritance
and this one
https://wiki.php.net/rfc/named_params#to_parameter_name_changes_during_inheritance
and most of this one
https://wiki.php.net/rfc/named_params#backwards_incompatible_changes
Regards,
--
Rowan Tommins
[IMSoP]
( $default=default && false ?: new ProxyLogger($default) );
That's even further into Obfuscated Code Contest territory than "default
=> default", and further reduces the reasonable use cases for expressions.
--
Rowan Tommins
[IMSoP]
ist of allowed
expressions.
Whether that's possible to enforce, in the parser, the compiler, or the
executor, I don't know. But if it's not, my opinion is that the entire feature
has an unanticipated problem that makes it unworkable. It would be a shame,
because on the face of it I can see the value, but sometimes you just hit a
dead end and have to turn back.
Regards,
Rowan Tommins
[IMSoP]
N_PRETTY_PRINT"
will immediately get a TypeError. With the feature in place, such an evolution,
which was previously safe, would become a hard BC break.
Forbidding that evolution, not just to that example, but to every function or
method with any default parameter, is too high a price to pay for the benefit
we'd get.
Regards,
Rowan Tommins
[IMSoP]
their types, can reliably be inspected and
used by callers in this way, we would logically need to declare any optional
parameter *invariant* (must match exactly in all child classes), which would be
a huge loss of functionality.
Regards,
Rowan Tommins
[IMSoP]
>been explicitly defined before now — due to the fact it wasn't relevant before
>this RFC — does not automatically require that it not be a formal part of the
>function signature, that is just the implicit status quo. This is likely
>something this RFC or a precursor RFC should ask voters to vote on explicitly,
>and then it would be decided.
Well, that would get an immediate "no" from me. I see absolutely no reason to
restrict a function's choice of default beyond being valid for the declared
type.
Rowan Tommins
[IMSoP]
On Mon, 26 Aug 2024, at 11:43, Mike Schinkel wrote:
>> On Aug 26, 2024, at 3:28 AM, Rowan Tommins [IMSoP]
>> wrote:
>> I was responding to someone justifying anything and everything the proposal
>> allows, because Reflection already allows it. If the feature was &q
t=new HttpClient) {}
None of these are, currently, breaking changes - the contract remains
"__construct(optional string $consulUrl, optional ?HttpClientInterface
$httpClient)".
Regards,
---
Rowan Tommins
[IMSoP]
alue
itself, only that the signature defines the parameter as optional. It's
actually a bit of a quirk that the interface has to specify a value, rather
than just stating this:
interface SimplifiedCompressionInterface extends CompressionInterface
{
public function compress(string $data, optional int $level): string;
}
Regards,
--
Rowan Tommins
[IMSoP]
On Mon, 26 Aug 2024, at 10:14, Bilge wrote:
> You're absolutely right, I would be interested to see any viable patch
> that effectively implements a set of restrictions on how `default` may
> be used. Requesting it be done at the parser level was not meant as a
> gotcha, that's just how I (with
On 26 August 2024 05:44:44 BST, Mike Schinkel wrote:
>> On Aug 25, 2024, at 12:21 PM, Rowan Tommins [IMSoP]
>> wrote:
>> The Reflection API is a bit like the Advanced Settings panel in a piece of
>> software, it comes with a big "Proceed with Caution" wa
On 25 August 2024 23:42:20 BST, Bilge wrote:
>On 25/08/2024 23:31, Rowan Tommins [IMSoP] wrote:
>> It doesn't, unfortunately, persuade me that the behaviour proposed is
>> sensible.
>
>It should. But since it has apparently failed in that regard, I suggest you
>
hat I've overlooked a reason why "expr ?: default" can't be
included without also including "default ?: expr", and will just have to take
your word for it.
It doesn't, unfortunately, persuade me that the behaviour proposed is sensible.
Rowan Tommins
[IMSoP]
in
extending that to "every optional parameter also acts a public constant that
the caller can read out and act on at will".
Rowan Tommins
[IMSoP]
;t have that property, so they require some
additional assumptions about the default, which might not hold in future. For
instance, if you use "default + 1", you are implicitly assuming that the
default value is not the maximum allowed value.
Rowan Tommins
[IMSoP]
nature that a new version of
the library has changed what _setup_default_blah() returns. If the
library doesn't provide an API to get $blah out later, then it's a
private detail that the caller has no business inspecting.
Regards,
--
Rowan Tommins
[IMSoP]
in which case, I've
no idea what that sentence was referring to.
--
Rowan Tommins
[IMSoP]
fuscate it.
Just because it's easy to implement a feature a particular way, doesn't
mean that's necessarily the right way.
--
Rowan Tommins
[IMSoP]
27;s declared as the default of some other
function passes that test.
Regards,
--
Rowan Tommins
[IMSoP]
efault to
your function signature, that is no information a user can pull *out* as
part of your API".
Regards,
--
Rowan Tommins
[IMSoP]
ther "conditions with default on the RHS" in my shortlist above
fit the same basic use case
Beyond that, I'm struggling to think of meaningful uses: "whatever the
function sets as its default, do the opposite"; "whatever number the
function sets as default, raise it to the power of 3"; etc. Again, they
can easily be added in later versions, if a use case is pointed out.
Regards,
--
Rowan Tommins
[IMSoP]
self: I agree that option 3 is the ideal in theory, but in
practice the short/medium term impact is so big, I'm not convinced it's worth
it for the long term gain.
Rowan Tommins
[IMSoP]
On 23 August 2024 20:50:05 BST, Rob Landers wrote:
>If it were global only, then how would I call those files?
>namespace\read_and_process_file()?
See my earlier posts, particularly https://externals.io/message/124718#125098
and https://externals.io/message/124718#125125
Rowan T
t;, and avoid them, why wouldn't we?
Your answer to that seems to be that you think "global only" is a bigger BC
break, but I wonder how much difference it really makes. As in, how many
codebases are using unqualified calls to reference a namespaced function, but
*not* shadowing a global name?
Regards,
Rowan Tommins
[IMSoP]
leaving some inconsistency, but
less compatibility break.
And most users don't object to using a leading backslash, they just (quite
reasonably) have no idea what impact it has on the ability of the engine to
optimise their code.
Regards,
Rowan Tommins
[IMSoP]
mean classes and functions resolve differently, and
that's why I said that if I had a time machine, I would support a different
option. But, personally, I don't think the small long-term inconsistency
outweighs the huge short-term disruption of defaulting to local.
Regards,
--
Rowan Tommins
[IMSoP]
On Fri, 23 Aug 2024, at 13:45, Mike Schinkel wrote:
>> On Aug 23, 2024, at 8:33 AM, Rowan Tommins [IMSoP]
>> wrote:
>> On 23 August 2024 13:04:22 BST, Mike Schinkel wrote:
>>> And how can it occur without an explicit `use
>>> AcmeComponents\SplineReticu
context where a
relative name would be assumed.
For example, \\domain\username and \\server\fileshare on Windows, or
//example.com/foo in a URL
Rowan Tommins
[IMSoP]
rent syntax, rather long and
unclear
return _\strlen("Hello World"); # short, but maybe a bit cryptic
return Text\strlen("Hello World"); # variable length, relies on current context
return NS\strlen("Hello World"); # shortening of current keyword
return self\strlen("Hello World"); # maybe confusing to reuse a keyword?
return current\strlen("Hello World"); # clear, but a bit long
--
Rowan Tommins
[IMSoP]
ace Acme\Foo\Utils;
function magic(string $x): int {
return \strlen($x);
}
function more_magic(string $x): int {
return magic($x) * 2;
}
Regards,
--
Rowan Tommins
[IMSoP]
in
any way by any of the proposals in this thread:
namespace Acme\Foo\Controller;
use function Acme\StringUtils\better_strlen;
use Acme\StandardUtils as Std;
$foo = Std\generate_something();
$len = better_strlen($foo);
\Acme\Debug\out($len);
Regards,
--
Rowan Tommins
[IMSoP]
t would behave in exactly the
same way that "namespace\Foo" already does.
--
Rowan Tommins
[IMSoP]
7;t seem mutually exclusive to me. If you have a file where you've
opted for "using global functions", you might want a way to reference a
function in the current namespace.
It also doesn't address my other point, that having global as the default mode
(even if we provide an option for local) is much less disruptive to existing
code.
Regards,
Rowan Tommins
[IMSoP]
r option would be to find a shorter keyword than "namespace" to put it in
front. "ns\strlen(...)" is an obvious step from what we have currently, but
it's not very obvious what it means, so maybe there's a different word we could
use.
Rowan Tommins
[IMSoP]
ing a function in one namespace is currently a lot
easier than setting up such a rewriter; but I don't think we should let
that convenience for a few use cases outweigh the benefits in
performance that a change in behaviour could bring, particularly when
combined with function autoloading.
--
Rowan Tommins
[IMSoP]
ns local" in
PHP 5.3, and we'd all be used to writing "\strlen" by now; but
"unqualified means global" feels much more achievable from where we are.
--
Rowan Tommins
[IMSoP]
That's not a small detail of the implementation, it's a really fundamental
difference from previous proposals.
So I would like to repeat my first response to your RFC: that it should sound
more time explaining your approach to the multiple lookup problem.
Regards,
Rowan Tommins
[IMSoP]
the same name.
Proposing both at once seems reasonable, as the autoloading gives an
extra benefit to outweigh the breaking change to shadowing behaviour.
Regards,
--
Rowan Tommins
[IMSoP]
;" but
it probably wouldn't feel very natural. It would be a syntax error to write
"include($path, $whatever)" just as "echo $foo, $bar" is valid, but "echo($foo,
$bar)" is not.
Regards,
Rowan Tommins
[IMSoP]
isting userland functions with that name. Between that and obviously serious
BC breaks like *removing* a function, there's a big grey area where we have to
make a judgement call.
Regards,
Rowan Tommins
[IMSoP]
tringable are a good idea, so I guess I'll just
leave y'all to it.
Regards,
Rowan Tommins
[IMSoP]
trings for backward
compatibility, and have this:
function fooThatTakesAnOption(FooOptionEnum|string $opt) {
if ( is_string($opt) ) {
$opt = FooOptionEnum::from($opt);
}
...
}
You might later want to use $opt->value, or $opt->getApiRepresentation(), or
whatever else; but at that point you know you have an object of a particular
type.
Regards,
Rowan Tommins
[IMSoP]
t how Unicode
works, but ideally we want to find meaningful abstractions of those
technicalities, not just require every user to understand them.
(PS I think I accidentally called you Rob just now; sorry!)
Rowan Tommins
[IMSoP]
ass that tries to "do Unicode" makes sense; it would
be like having a "maths class" that contains methods for anything dealing with
numbers.
In fact, I think the group of functions you're suggesting are a great
illustration of what I was saying in my last message to Rob: they make perfect
sense as standalone features, and don't need any grand plan to "have Unicode in
core" before we proceed with them.
Regards,
Rowan Tommins
[IMSoP]
ding
>Unicode into the standard library?
I was just summarising the current situation, to work out where we could go
next. Any attempt to extend string handling functionality is likely to build on
either ext/intl or ext/mbstring, so it's useful to understand how they differ.
Regards,
Rowan Tommins
[IMSoP]
open RFC implementing option (b) by Gina and Dan
here: https://wiki.php.net/rfc/core-autoloading Last I heard, Gina was
still hoping to get back to it.
On a different note, there is no mention of autoloading namespaced
constants in this RFC, unlike in some previous proposals. Is this a
conscious decision to leave them out of scope, or an oversight?
Regards,
--
Rowan Tommins
[IMSoP]
even add C++ (or Rust, Go, etc) APIs for already released versions
of the engine.
Regards,
Rowan Tommins
[IMSoP]
ke "what script does this
code point belong to?" or "what is the uppercase equivalent of this
grapheme, assuming a Turkish locale?"
--
Rowan Tommins
[IMSoP]
ut few
actually engaging with the question of what that actually means. Often they
equate "character" with "code point" and stop there, which leads to results
that are just as useless to most of the world as if they'd equated it with
"byte".
Regards,
Rowan Tommins
[IMSoP]
headers,
which are not reset based on a new subject line.
In those UIs, this is still part of the completely unrelated deprecation voting
thread <https://externals.io/message/124506>, which was already becoming
unmanageably long due to the protracted debate about hashing functions.
Regards,
Rowan Tommins
[IMSoP]
On Fri, 2024-08-02 at 18:53 +0100, Rowan Tommins [IMSoP] wrote:
> There was a proposal for exactly this a few years ago, which ended up
> in an RFC with a slightly different syntax (using a declare()
> statement), but was declined in voting by 35 votes to 2.
Sorry, I forgot the li
ghtly different syntax (using a declare() statement), but was
declined in voting by 35 votes to 2.
I can't remember much about the discussion, so am not sure what changes would
make a new attempt more likely to pass.
Regards,
Rowan Tommins
[IMSoP]
the standalone
function, but keep the algorithm fully available in hash().
Regards,
--
Rowan Tommins
[IMSoP]
ha1_file() functions
are not part of the hash extension, it's also much harder for the user
to discover the incremental hashing functionality provided by
hash_init().
Again, that seems easily solved: ext/hash is now always-on, so moving
the functions there from ext/standard would ha
a function for power users who already know something
about the subject, then yes, maybe. If we're telling everyone to look it up
when they thought they were going to use sha1(), then we need to give them
something to read when they get there.
Regards,
Rowan Tommins
[IMSoP]
some calculation to choose SHA-382
or SHA-512, please let me know. But don't assume that just forcing me to put
the algorithm name in qoute marks is going to make me know, or care, what the
name actually means.
Regards,
Rowan Tommins
[IMSoP]
t fits nicely in the manual.
As long as the deprecation rests on "somebody in the next 10 years might get
round to improving the manual", my vote remains a firm No.
Regards,
Rowan Tommins
[IMSoP]
The RFC is suggesting that we take away their
flat-head and Phillips screwdrivers, and leave them with the 60-piece set, and
no instructions.
My suggestion is we instead give them a Pozidriv screwdriver, and write some
tips on how to use it correctly.
Regards,
Rowan Tommins
[IMSoP]
to that
documentation. Deprecating md5() and sha1() does neither.
Regards,
--
Rowan Tommins
[IMSoP]
mpelled to point out that
> SHA-256 and SHA-512 are both SHA-2. If one is broken, it is likely that
> the other is as well.
Again, you know that, but do the users you're trying to help by deprecating
sha1()? I'm a reasonably experienced developer, and I have no idea why SHA-512
would exist if it's not in some way "better" than SHA-256.
Regards,
--
Rowan Tommins
[IMSoP]
nd-replace from "sha1(" to "hash('sha1', " and gain nothing.
The deprecation *might* make sense alongside introducing some new functions
that we want people to discover instead, but on its own, I don't think the
benefits outweigh the costs.
Regards,
Rowan Tommins
[IMSoP]
ction is, I don't think it's practical for a
lot of the places hashing is used.
Regards,
Rowan Tommins
[IMSoP]
ours of "sha3"? Then there's the fun-sounding
"whirlpool", the faintly rude-sounding "snefru", and a bewildering
fifteen flavours of "haval".
A new user being told "don't use sha1(), use hash() and pick from this
list" is more likely to say "ah, there's sha1, jolly good" than spend an
afternoon reading cryptography journals. There's no pit of success to
fall into.
Regards,
--
Rowan Tommins
[IMSoP]
a different process would have done better - there have been changes which
went through a whole RFC process, then a year later someone points out a flaw
that could have been avoided; that's life.
Now that we have spotted it, we need to decide what to do.
Regards,
Rowan Tommins
[IMSoP]
users: those whose
code contains "parse from" *without* extra comments, which will now emit two
tokens instead of one. They will suffer if tools are not updated to handle this
change.
Reverting now, and *later* implementing the feature a different way will impact
multiple of these groups, just at different times.
Regards,
Rowan Tommins
[IMSoP]
been allowed.
The Ubuntu LTS situation is unfortunate, but maybe Ondřej Surý will have an
opinion on what to do with the patch there.
Regards,
Rowan Tommins
[IMSoP]
eir existing plugin installer system -
which already has a system for metadata, it doesn't need a new config file -
and persuading plugin authors to actually use it.
Maybe you also need Composer to make some changes to control it without the
CLI, so plugins can list their requirements and have
flavour of the language, just to make use of a new feature that has
nothing to do with those changes.
Rowan Tommins
[IMSoP]
On 10 July 2024 19:08:39 BST, Michael Morris wrote:
Just to repeat a point that's been raised a few times: this is not a great time
of year for this kind of discussion. If you come back after 8.4 is baked, you
may get more enthusiasm. That will also give you time to make some more
detailed
ter those directory or
file lists, e.g. when you install a WordPress plugin, something has to load its
configuration file
- PHP still won't be able to have two classes with the same name, because
that's a completely separate problem, unrelated to autoloading
Regards,
--
Rowan Tommins
[IMSoP]
asses with the same fully-qualified name,
because the language has no base functionality to build that on. Designing
configuration files is a complete waste of time until you've designed that base
functionality: when you load two classes with the same fully-qualified name,
what exactly do you want the engine to do? What will need to change in the core
of the language to make that possible?
Regards,
Rowan Tommins
[IMSoP]
happens next, in the
language itself, to make them live side by side without breaking? If we get a
solid solution to that (which I'm skeptical of), we can discuss how Composer,
or the WordPress plugin installer, would generate whatever
include/import/alias/rewrite statements we end up creating.
Regards,
--
Rowan Tommins
[IMSoP]
Rowan Tommins
[IMSoP]
On 1 July 2024 15:37:49 CEST, Alexander Pravdin wrote:
>I personally support the movement from the current "plain-text
>template-first" language to a "coding-first" language, where files
>contain code by default.
I honestly don't read the
nds of
applications built on their current packages.
Other parts of this thread are just random rants about things people don't like
in PHP, which I have zero interest in, and have nothing whatsoever to do with
modules or package management.
Rowan Tommins
[IMSoP]
res some characteristics with what we have,
than to rewrite the language to fit a design which shares none.
The descriptions of the *design of packages* in JS and Go make me think they
don't have enough in common with PHP to be easy to apply, so I'm suggesting we
look at other designs.
Rowan Tommins
[IMSoP]
1 - 100 of 1013 matches
Mail list logo
