$v = 2;
}
Why should C2 have the right to break the expectation of C in that way?
Rowan Tommins
[IMSoP]
lt in a constructor,
but that is not the case. (https://3v4l.org/5iIak vs https://3v4l.org/rL8pX)
I'm inclined to agree that this is a bug, regardless of whether it's difficult
to fix in the implementation.
Rowan Tommins
[IMSoP]
one property, no
matter how many times in the inheritance chain it is redefined.
Rowan Tommins
[IMSoP]
ates back to the original example in the thread, I'm not
sure, but it's definitely not "shadowing" in the same sense as a private
property.
--
Rowan Tommins
[IMSoP]
pecific* feedback in design
discussions, rather than vague assertions that we're spending time on the
"wrong" features.
Rowan Tommins
[IMSoP]
ementation; I'm just exploring what kinds of short-hand might be useful.
--
Rowan Tommins
[IMSoP]
his would replace all Warnings. Think of
it more as replacing the "returns false on error" part of the fopen()
signature.
If we decide to add something like the above I would very much prefer the try
... ignore block to be an expression with value null on error, making the first
line obsolete.
Good point, I agree.
--
Rowan Tommins
[IMSoP]
management).
That doesn't mean your use case isn't valid, but it's like saying "it's
not a knife, it's merely a sharpened metallic implement used to cut things".
--
Rowan Tommins
[IMSoP]
he exception didn't build
a full stack trace then immediately discard it - this was touched on in
Larry's thread a while back https://externals.io/message/127188
--
Rowan Tommins
[IMSoP]
quot;catch(Foo){}" is allowed in your
local coding standard.
--
Rowan Tommins
[IMSoP]
about string inputs, it's talking about
values that are already floats. The fact that you can't create one from a
string cast doesn't seem relevant, if you have in fact created one some other
way.
https://3v4l.org/efucd
Rowan Tommins
[IMSoP]
n
32-bit platforms
or, perhaps clearer, use an out-of-range string input:
is_representable_as_int('2147483648'); // true on 64-bit platforms,
false on 32-bit platforms
Regards,
--
Rowan Tommins
[IMSoP]
s, but stalled on a) naming; and
b) what a "safe" cast means for different types. It seems like both
problems have already come to light in this thread.
--
Rowan Tommins
[IMSoP]
sitiveParameter], could we also have
#[SkipCallInTrace]? Could we have a way to construct an exception with a
custom trace?
As long as the format is correct when written to the private property,
we don't need to change existing code that reads directly from that
property.
--
Rowan Tommins
[IMSoP]
'9007199254740991000') == false // more than 2**53
can_lossless_cast('9007199254740991000') == true
can_lossless_cast('3.5') == true
Regards,
--
Rowan Tommins
[IMSoP]
) The function needs a better name, to avoid confusion over what "safe" means.
Regards,
Rowan Tommins
[IMSoP]
On 10 July 2025 01:52:17 BST, Deleu wrote:
>On Wed, Jul 9, 2025 at 7:23 PM Rowan Tommins [IMSoP]
>wrote:
>
>> On 09/07/2025 17:39, Deleu wrote:
>> > It's currently undeniable that a Unit Enum name is a string.
>>
>> If you want to associate a single s
source code, useful primarily for debugging.
If you want to associate a single string value with each enum case, use
a string-backed enum, and propose some short-hand syntax. Please leave
unit enums as opaque objects for those of us who see value in that.
--
Rowan Tommins
[IMSoP]
ific short-hand syntax on the case, like "case
ZendFramework = auto" or "case ZendFramework = _".
Rowan Tommins
[IMSoP]
ile, even including the return code:
exit( main() );
Is there a specific scenario where you see an automatic call being a
significant improvement over that line?
Rowan Tommins
[IMSoP]
utes used, so updating the validation in setcookie() probably does make
sense, with the expectation that it will become widely supported within the
next year or two.
Rowan Tommins
[IMSoP]
just makes all data "☺" for example, to indicate you're
>working with unsanitised data. (I don't think there is such a filter
>though).
Perhaps the option should be something like "filter.mandatory=1", blanking or
poisoning the superglobals and obliging users to go through filter_var?
Rowan Tommins
[IMSoP]
not a huge fan of the filter extension, but don't see any particular
reason to remove this one feature of it.
Rowan Tommins
[IMSoP]
ase64_decode with Mode::Strict or
> Mode::Lenient instead.
And the main documentation for Encoding\base64_decode could explain all three
modes side by side.
What do you think?
Rowan Tommins
[IMSoP]
don't want is to
indefinitely have two versions with such similar names but different signatures.
Rowan Tommins
[IMSoP]
send output to a write callback.
That makes a lot of sense! I've never been very good at keeping names
and sentences short :)
--
Rowan Tommins
[IMSoP]
T_WRITEFUNCTION
would then not exist in the option enum(s), because there would be no
way to make use of them.
Unlike the helper methods, that's one we have to decide in advance - it
would be a mess to have those *as well as* a universal "execute(): ?string".
--
Rowan Tommins
[IMSoP]
n does
not: https://dom.spec.whatwg.org/#ref-for-dom-element-getattribute%E2%91%A0
Rowan Tommins
[IMSoP]
x27; or 0 for those cases, but feels more logical as a design.
Rowan Tommins
[IMSoP]
iner and its host application, but I think for *those* it is
safe to list individual items, because you're not trying to pull their
dependencies, just point to the right piece of code.
Rowan Tommins
[IMSoP]
D{ public function foo(): never {} }
That seems reasonable enough; I may have missed something important, though.
Regards,
--
Rowan Tommins
[IMSoP]
file system wrapper; you still have to include/require
the individual files inside the archive, and they're still compiled in
exactly the same way.
Whether we want to isolate "any definition you find in the directory
/var/www/wordpress/wp-plugins/foo/" or "any definition you find in the
Phar archive phar:///var/www/wordpress/wp-plugins/foo.phar", the tricky
part is how to do the actual isolating.
--
Rowan Tommins
[IMSoP]
kage ever written. Probably
some caveats where dynamic code can accidentally escape the container.
Completely separate from the kind of "module" you and Arnaud were experimenting
with.
Rowan Tommins
[IMSoP]
ses, but at this point every JS
module going back 15+ years (CommonJS was founded in 2009, to
standardise existing practices) is based on the "interact by export"
model; and every PHP package going back 25+ years (PEAR founded in 1999;
Composer in 2011) is based on the "interact by name" model.
--
Rowan Tommins
[IMSoP]
al" flag as they are if they use reflection or
code-rewriting to ignore/remove the "private" flag.
Rowan Tommins
[IMSoP]
quot;@internal" annotations, or
future "module private" declarations, and make whatever other changes are
needed to suit your use case.
Regards,
Rowan Tommins
[IMSoP]
his was suggested a couple of times on the previous thread. It
would be a useful feature, but probably not easy to implement efficiently and
integrate thoroughly into the language.
Regards,
Rowan Tommins
[IMSoP]
t;export", any reference to
any class name is prefixed in the same way, and loaded with the isolated
autoloader stack. To the host application, and any other plugins, the
code inside the "wp-plugins/AlicesCalendar/vendor" and
"wp-plugins/BobsDocs/vendor" directories is entirely hidden.
--
Rowan Tommins
[IMSoP]
l the same setup
// It lists its own imports and exports, and uses its own unique prefix
// Any relationship between the two plugins happens in the WordPress
Core code as usual
```
The guiding principle is that the code inside the container should need
as little modification as possible to be compatible, so that all the
code on packagist.org immediately becomes available to whatever plugin
wants it.
--
Rowan Tommins
[IMSoP]
portantly, all of this should happen on the *PHP symbol* level (classes,
interfaces, functions); the sandboxing mechanism doesn't need to know about
package managers - just as Docker, Kunernetes, etc, don't know about APT / Yum
/ whatever Apine calls it.
Rowan Tommins
[IMSoP]
isting code to change from one to the other, especially
since they won't be able to for several years if they support multiple PHP
versions.
As for other languages, they use all sorts of different keywords for the same
or similar features, e.g. "import" and "using", so
". All the classes
that are "inside" are completely sandboxed from the classes "outside", without
needing any interaction with a package manager.
As far as I know, this is how existing userland solutions work, and I haven't
yet spotted a reason why it needs to be any more complex than that.
Regards,
Rowan Tommins
[IMSoP]
wing, or whatever) we need some requirements of *what* we want to
rewrite. By suggesting an image of "containers" or "sandboxes" rather
than "packages" or "modules", I was trying to define the requirement
that "AlicesCalendar and BobsDocs are special, in a way that
monolog/monolog and google/apiclient are not".
--
Rowan Tommins
[IMSoP]
On 21 May 2025 13:26:27 BST, "Rowan Tommins [IMSoP]"
wrote:
>
>My understanding of the example is that there are two WordPress plugins, which
>want independent sets of Composer dependencies. There might be 20 different
>Composer packages used by each plugin, but tho
ree, so I
don't know what else I can say.
Rowan Tommins
[IMSoP]
any de-duplication of files on disk
that a package manager might perform. It's a bit like the same C source file
being compiled into two different object files with different #defines in
effect.
I'm still not convinced that all this complexity actually leaves you better off
than building a Composer plugin that automatically applies the rewriting to a
whole directory at source code level.
Rowan Tommins
[IMSoP]
erty to
a new value
The question then is, how worried are we about that scenario?
--
Rowan Tommins
[IMSoP]
for Linux containers as an alternative
analogy, to think about the problem without jumping to the wrong solution.
Rowan Tommins
[IMSoP]
sses") but that's
a completely separate concept.
I wasn't saying the feature had to be called "containers", just that the
analogy might be useful.
Rowan Tommins
[IMSoP]
ot just plugin1 itself, but all the third-party code it calls, into
some kind of sandbox, as though it was running in a separate process. If you
can control what classes can go into and out of that sandbox, then in any piece
of code, you don't end up with conflicting meanings for the same name - just as
a Linux container can't open a network port directly on the host.
Regards,
Rowan Tommins
[IMSoP]
;containers", in the sense of Docker, Kubernetes, etc, where
different sections of code can be isolated, and declare classes with
conflicting fully-qualified names. I don't think it's what most applications
and libraries would want "modules" to be; it's probably best thought of as a
completely separate feature.
--
Rowan Tommins
[IMSoP]
On 7 May 2025 21:51:29 BST, Michael Morris wrote:
>On Wed, May 7, 2025 at 3:24 PM Rowan Tommins [IMSoP]
>wrote:
>
>Other libraries have the means to import into a namespace because their
>namespaces aren't just a quick and dirty string replacement. I've even
>pro
not* think that allowing multiple versions of the same
library should be a core requirement of any native module support;
enabling userland to achieve it efficiently would be a nice to have.
--
Rowan Tommins
[IMSoP]
adowing would instantly become
a conflict anyway; and I can't picture how "protected" would work.
--
Rowan Tommins
[IMSoP]
ed against the benefit, but not a blocker
in itself.
--
Rowan Tommins
[IMSoP]
x of the library.
Probably they will be currently marked "@internal" or highlighted in
documentation in some way, to indicate that they are not intended as part of
the public API; the only difference will be that now you'll get an error if you
ignore that documentation.
Rowan Tommins
[IMSoP]
class' class name that is
>marked `@internal`.
The value-add is 1) that they enforce the visibility at the language level, and
2) that they allow a concise syntax for declaring a set of closely related
classes.
I'm not wholly convinced that they do that better than "file private" or
"module private", but I don't agree that "class hiding" is essential, or even
particularly desirable.
Rowan Tommins
[IMSoP]
re
some use cases would be possible, and some would have easier work arounds than
today. Possibly we could slowly add places the syntax is allowed, where we can
make it make sense without tackling the tricky parts like variance/inheritance
and type inference.
Rowan Tommins
[IMSoP]
o a separate RFC" does not mean "released in a different
version of PHP", it just means "has more space to discuss details". There's so
much to decide here, that we should take any chance we can to break it into
smaller pieces.
Rowan Tommins
[IMSoP]
other comment at a very quick glance is that I see the Context section
is still included, and still has most of its complexity. As I said about the
previous drafts, this seems to be an optional extra that can and should be
proposed in a follow-up.
Thanks again for your hard work, but let's not rush this.
Rowan Tommins
[IMSoP]
e line
where Closure::getCurrent() is called.
--
Rowan Tommins
[IMSoP]
ture it into another closure
$bOutside = function() use ($aInside) {
// Get a self-reference in that one too
$bInside = Closure::getCurrent();
// Do whatever you like with $aInside and $bInside
};
};
Rowan Tommins
[IMSoP]
mance and
side-effects of capturing the original values. This wouldn't solve the
sensitive information problem, though, so I'm not sure how good an idea
it would be.
--
Rowan Tommins
[IMSoP]
s, or the state of opaque objects and resources like file/stream
handles.
Collecting arguments seems like a special case which could be handled by
debug or APM extensions, rather than something that most users will ever
need.
--
Rowan Tommins
[IMSoP]
ve never used
it or seen it used; normally, trim($foo)==='' (or trim($foo??'')==='') seems to
be good enough.
Rowan Tommins
[IMSoP]
le $fn, mixed ...$fixedArgs): callable {
return fn(mixed $firstArg) => $fn($firstArg, ...$fixedArgs);
}
// first-arg chaining
$someChain |> array_filter(fn($v, $k) => $k === $v, ARRAY_FILTER_USE_BOTH);
// native partial application
$someChain |> array_filter(?, fn($v, $k) => $k === $v,
ARRAY_FILTER_USE_BOTH);
// workaround
$someChain |> partial_first(array_filter(...), fn($v, $k) => $k === $v,
ARRAY_FILTER_USE_BOTH));
--
Rowan Tommins
[IMSoP]
h of
statements I want to run in a new Coroutine, but they're not worth putting in a
function". So to the user, having all the features of a function isn't
relevant. We don't allow specifying the return type of a match statement, for
example.
Do you have a different scenario in mind?
Rowan Tommins
[IMSoP]
ly implemented extension
methods instead of pipes, and then the new iterator API was
extension-method-only. It feels less like "one of the arguments is
missing" if that argument is *always* expressed as the left-hand side of
an arrow or some sort.
--
Rowan Tommins
[IMSoP]
ded up
how they did.
--
Rowan Tommins
[IMSoP]
he description of traits (they would no longer
just be copied and pasted code), and would lead to additional questions (e.g.
what happens when the target class changes the visibility with an "as" clause?).
Any inconsistent behaviour should have to clear a high bar.
Rowan Tommins
[IMSoP]
or a property.
I see no reason for inheritance to be involved at all. If we want an access
level that means "accessible from any code in this file, or any subclass of the
current type", we can make up a keyword for that as well - "fileprotected", or
"fileprivate_or_protected", or whatever.
Rowan Tommins
[IMSoP]
t.
A "fileprivate"/"samefile" keyword would be pasted into the file it was used
in, and mean accessible within that file; it wouldn't matter what file the
trait was defined in. It would probably be useless, but lots of useless code is
possible in any language.
Besides, all these questions have to be answered for nested classes as well.
Just because you've reused the keyword "private" rather than adding
"private_or_nested", you still have to define exactly what it does and doesn't
allow access from in these new scopes.
Rowan Tommins
[IMSoP]
On 25 March 2025 18:14:21 GMT, Daniel Scherzer
wrote:
>On Tue, Mar 25, 2025 at 11:01 AM Rowan Tommins [IMSoP]
>wrote:
>
>>
>> I don't think the language should pretend to support something that it
>> doesn't
>>
>
>I don't see what the pr
On 25 March 2025 16:42:45 GMT, Robert Chapin wrote:
>On 3/25/2025 4:45 AM, Rowan Tommins [IMSoP] wrote:
>> The implied default in the first is 'off', but in the second it's 'on'.
>I thought the implied default was null.
By "implied", I'm
coalesce($_POST['tick']) != 0) return;
But this doesn't:
if (coalesce($_POST['tick']) !== 0) return;
By specifying the default explicitly, we don't have to examine the expression
carefully to see what's implied.
I don't know if I'd go as far as banning a single-argument coalesce, but I
would definitely discourage its use.
Rowan Tommins
[IMSoP]
choice - { contains, contained by, neither }.
File scope gives us instead the dimension { same file, different file }; and
module scope gives us { same module, different module, no module }, and maybe
some additional relationships between modules.
Rowan Tommins
[IMSoP]
=== 'yes') echo 'success';
if (($_POST['input'] ?? $_GET['input'] ?? 'N/A') !== 'N/A') echo
'meaningful value provided';
if (coalesce($_POST['input'], $_GET['input'], 'N/A') !== 'N/A') echo
'meaningful value provided';
--
Rowan Tommins
[IMSoP]
extend current
functions to handle IRIs?", I'd start from the point of "what functions do we
need for handling URI/URL/IRI parts, and what variations of each?"
Rowan Tommins
[IMSoP]
function signature because it used to directly overwrite variables by name.
As a comparison, we didn't extend the shuffle() function with an
algorithm parameter, we added a shuffleArray() method to the new
Randomizer class.
--
Rowan Tommins
[IMSoP]
the contract in a docblock:
/**
* @template T
* @method compareTo(T $other): int;
*/
interface Comparable {
}
/** @implements Comparable */
final class Number implements Comparable {
public function compareTo(Number $other): int { return $this
<=> $other; }
}
--
Rowan Tommins
[IMSoP]
n, though, this could easily be added later when a need becomes
visible, as long as we don't do something weird now that closes the door
on it.
I suggest we leave this sub-thread here; there's plenty of other things
to discuss. :)
--
Rowan Tommins
[IMSoP]
se: it will be used frequently.
Will it? By who, when? Honest question, and comes back to my point about
identifying the use case.
>For example, `spawn fn() => file_get_content()` won’t be, because it
>doesn’t make sense.
If return values end up somewhere, I don't think it would be hard to come up
with examples that were slightly more than one function call, but still fit in
a single-expression closure.
Rowan Tommins
[IMSoP]
f the aim is "a readable way to use a closure", rule #2 is fine.
Yes, it means some extra parentheses if you squeeze it all into one
statement, but it's probably more readable to assign the closure to a
temporary variable anyway:
// Legal under rule #2, but ugly
spawn (function() us
actoring like moving that
declaration into a variable.
If it's going to be a special case for an "inline coroutine", just use a
keyword other than "function", so it doesn't look like an expression when it's
not, like "spawn block { ... }"; or no keyword at all, just "spawn { ... }"
Rowan Tommins
[IMSoP]
eted as if `something` is a PHP constant rather than a
>function.
It's more fundamental than that: function_call and expr are overlapping
grammars, so having a rule that spawn can be followed by either of them, with
different meanings, leads to ambiguities. You can carefully tune the grammar to
avoid those, but then the user has to learn those rules; or you can just use
two keywords, which I don't remember you actually responding to as a suggestion.
Rowan Tommins
[IMSoP]
est("string");
Or forget callables, and anything that looks like it's trying to be one,
because creating a Closure isn't actually the user's aim:
spawn_this_function_call_without_creating_a_closure test("string");
spawn_these_statements_use_a_closure_if_you_like_i_dont_care {
do_something();
do_something_else();
}
--
Rowan Tommins
[IMSoP]
choosing between creating a child within a
narrow scope you've just opened, vs creating a sibling in the scope created
somewhere up the stack.
The "request handler" use case could easily benefit from a "pseudo-global"
scope for each request - i e. "tie this to the current request, but not to
anything else that's started a scope in between".
There were also some concrete examples given in the previous thread of
explicitly managing a context/scope/playpen in a library.
Rowan Tommins
[IMSoP]
expanding recursively to function_call, as in the add(1)(2) form beloved
of Function Programmers
Is there a reason to redefine all of this and make fresh decisions about
what to allow?
I would argue for "principle of least surprise": reuse or emulate as
much of the existing grammar as possible, even if you personally would
never use it.
--
Rowan Tommins
[IMSoP]
rsonally, I would be equally happy with either \ or :: and less happy with
anything that required us choosing yet another set of punctuation, for what is
otherwise quite a minor feature in its language impact.
Rowan Tommins
[IMSoP]
al
syntax might make more sense - there would be a very specific
relationship between the inner and outer classes. I don't think "has
special visibility of members, like a friend-class or file-private
feature" needs to be highlighted in the syntax that way.
--
Rowan Tommins
[IMSoP]
ead.
> So, maybe, it could be useful to use \ but in the long run, I’m not sure it
> makes sense.
I rather think the other way round: in the short term, a new separator would
save users a bit of pain with autoloading, but in the long run it will look
like a weird anomaly that no other language needs.
Rowan Tommins
[IMSoP]
e application malfunctions.
This and other special behaviours suggest that this should inherit from
Error rather than Exception, or possibly directly from Throwable
That's all for now. To reiterate: thank you so much for working on this,
and I really like the shape it's beginning to take :)
--
Rowan Tommins
[IMSoP]
\InnerClass" }
The quadrupled namespace separator is still just about readable, but
could you tell me at a glance if I have the right number of backslashes
for the proposed inner class separator?
If we can't use "::", I'm confident we can find one that's more
convenient to use than double-backslash.
--
Rowan Tommins
[IMSoP]
firewalls" in the application, where any accidentally orphaned
coroutines can be automatically awaited before declaring a particular task
"done". But Daniil is probably right to ask for concrete use cases, and I have
not used enough existing async code (in PHP or any other language) to answer
that confidently.
Rowan Tommins
[IMSoP]
des")->build();
The "User" class would have a "file private" or "namespace private"
constructor, callable from the "User\Builder" class but not elsewhere; the
build() method would return the "User" instance.
I think I'm coming to the conclusion that we should use backslash: nested types
can be viewed as a shorthand way of having a class and namespace with the same
name, plus applying some visibility rules to that namespace.
Rowan Tommins
[IMSoP]
mming-language/accesscontrol/
The example of a nested enum also demonstrates a nice shorthand syntax,
where the ".ace" in "BlackjackCard(rank: .ace, suit: .spades)" is short
for BlackjackCard.Rank.ace, inferred from the parameter type.
I don't have any specific conclusions, but I think with features like
this it's always worth examining other people's ideas, to see if we want
to include (or avoid) any of them.
--
Rowan Tommins
[IMSoP]
dered wrong here: https://externals.io/message/126589#126741 (compare
here: https://news-web.php.net/php.internals/126741)
The other thing I wonder is whether the original reason why `::` wasn't
used as the namespace separator still applies, and needs to be accounted
for here?
--
Rowan Tommins
[IMSoP]
t proposals complement rather
than blocking each other: iterator functions make pipes more efficient to use,
and pipes make iterator functions more pleasant to use. I'd like both please. :)
Rowan Tommins
[IMSoP]
, and give
every annual release equal status. This is the approach that PostgreSQL
has taken, I believe.
We'd probably still want some kind of deprecation policy - some changes
should be deprecated for X releases before removal/change. Which brings
us back to some kind of criteria for which changes need that, so doesn't
really solve the problem.
--
Rowan Tommins
[IMSoP]
letely new API to eliminate) and "this is bad, and there
are concrete plans to change it" (e.g. it will become an error, or start
doing something different, in the next major version).
--
Rowan Tommins
[IMSoP]
1 - 100 of 338 matches
Mail list logo
