ckages
on Packagist using https://github.com/nikic/popular-package-analysis -
perhaps Juliette has already done that when testing their PHPCompatibility
sniff?
Regards,
--
Rowan Tommins
[IMSoP]
g existing behaviour to accept null for
non-nullable parameters (interestingly, until PHP 8.0, htmlspecialchars()
could return null, e.g. if given an array). Unfortunately, that would be a
different kind of compatibility break, so I'm not sure it fully solves the
problem.
Regards,
--
Rowan Tommins
[IMSoP]
st this worth the backwards compatibility cost of
changing the behaviour, and requiring extra code in other scenarios?
Possibly not. But that's different from not having any benefit.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On 05/04/2022 19:45, Rowan Tommins wrote:
Good evening all,
I have opened voting on the RFC to Deprecate and Remove utf8_encode
and utf8_decode:
https://wiki.php.net/rfc/remove_utf8_decode_and_utf8_encode
I am pleased to announce that this RFC has been Accepted with 33 Yes
votes and 2
$foo)
$foo |> htmlspecialchars(...)
Then this could be equivalent to ($foo === null ? null : htmlspecialchars($foo))
$foo ?|> htmlspecialchars(...)
I'm not set against this RFC, but I'm not quite convinced by the case it makes,
and think there may still be other options to explore.
Regards,
-
he
links about what features are likely to be most useful to people?
I look forward to seeing a draft RFC, which can take the time to explain
the features you think are needed.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
' === 0, but passing 'hello' to an
int parameter is an error regardless of mode, as is 'hello' + 1
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
3' being
considered numeric - occasionally useful, but probably not worth the
potential confusion of a special case.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
8.1 as soon as possible but only tackling the
deprecations when time allows is absolutely the right thing to do.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
the value in the decision made back in 7.0 to exclude nulls by
default.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
being private
when assigned a new value. Given that we have the magic "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)'
Regards,
RFCs trying to fill in the gaps.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
where on this thread. On the
one hand, they should probably match with at least some existing rules;
on the other, it would be weird to introduce them then immediately
deprecate some behaviour because we've decided to make the language
stricter elsewhere.
Regards,
--
Rowan Tommins
[IMSoP]
--
is not a valid call.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
e what's really needed is to draft a new copy of the policy document,
updating or removing those parts that are no longer relevant, and adding a
timeline for the pre-release phases?
Or possibly there's a different document I should be looking at, and the RFC
could contain proposed edits to that?
eclare() covers.
Wherever it is used, "null" is a confusing and often controversial
concept. In different contexts, it is used for different things, and has
different ideal behaviours. It's a whole debate on its own, and bringing
in other types of coercion just confuses the conversation.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
if the [imaginary] sql_escape function doesn't reject
nulls, you may not notice the bug until you've ended up with garbage in
your DB.
Regards,
--
Rowan Tommins
[IMSoP]
hould be done on output not
input, but it's not completely infeasible that that combination might
happen.)
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
o*$foo*$foo?
I don't really have a conclusion here, I just wanted to throw it out there as a
different mental model to consider.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
. But that's not really relevant because there
are plenty of programming languages which have multiple quoting styles
without using it, mostly by adding a prefix, e.g. Python's f"...".)
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
rrently planned change, but I don't think loosening the existing type
rules on user-defined functions is a good solution.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
e, the benefits have been explained repeatedly in this thread.
You may not agree that they are worth the cost, and as I've repeatedly
said, I have some sympathy for that. But please stop trying to take the
conversation back to the very beginning by implying that you've asked a
question and not rec
t;future changes" which
are being prevented.
The only other change is a few renamed constants, which I suggested on the
PR. I can see an argument for making them match the library exactly; but
it's the *values* that actually matter, so I don't see why we shouldn't
choose our own names if they
nd whether to emulate the older behaviour (or indeed emulate the newer
behaviour on systems with an older library).
Twenty years ago, maybe PHP programmers were used to it being a veneer over C.
I don't think that is or should be the expectation today, unless you're using
FFI.
Regards,
--
Row
in the wrong way, or the wrong circumstances, and actually making their
code less secure.
Because of all of the above, I have cast a No vote, because I would
rather the right implementation was delayed until PHP 8.3 than the wrong
implementation rushed into PHP 8.2.
Regards,
--
Rowan Tommins
gn of having mutable setters; as Derick pointed out, mutable value
objects are generally a bad idea, so it would make sense to encourage
users to think of this as a way to get one or more strings, rather than
as a result in itself.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP
of strings, then it really has very
little in common with how I think of (unbacked) enums, but maybe that's
fine.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
y supposed to use CurlUrl when
interfacing with curl, and generate the string myself for other
purposes? If the implementation I come up with differs from curl's, how
does the user know which is the "real" URL?
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Develo
d what correct
usage looks like. Just providing a bunch of functions, in whatever form,
doesn't provide security unless users can understand how to use them
securely.
Regards,
--
Rowan Tommins
[IMSoP]
offers
neither opt-in nor opt-out, relying on the implementation to do the
right thing automatically ... most of the time.
To re-iterate, I am not opposed to the feature in principle, but would
have loved to see a more open exploration of different syntax options.
Regards,
--
Rowan Tommins
[IMSoP]
unlikely that this change will make people suddenly use
traits in more "wrong" places, nor prevent any alternative horizontal
reuse / composition aid features being added in future.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscr
lly tagged "Waiting on Author", but I have no way to
switch that back to "Waiting on Review" now that I've resolved the comments.
Thanks,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ging the value
referenced by all 3 members
// refcount on the resource drops from 1 to 0, triggering the destructor
$fn();
// because it was captured by reference, the initial value of
$some_resource in the closure has now changed
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Devel
, and "return" returns from the doSomething() function,
not the transaction wrapper.
The explanation of how Python's implementation works and why is an
interesting read: https://peps.python.org/pep-0343/
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ssion closure would have any local variables. Indeed,
that lack of local scope is one of the big reasons why I and others
supported that RFC, because it avoids all the confusion evident in
today's messages.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
. The fact that a variable of the same name, whose
value is never actually used, is captured by the closure, is to me a
bug, not a feature.
It's hard to even contrive an example where this is observable, so I
highly doubt anyone is relying on it.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Inter
ugh. What if, rather than implementing __toString() as such, we
implemented internal cast handlers for either string or int, depending on
the backing value? (Other internal objects do have this ability, e.g. GMP
and SimpleXMLElement)
Regards,
--
Rowan Tommins
[IMSoP]
t of values, and a consuming app
wanting to constrain that set within its own code.
It's one disadvantage is the typo-proofing and look up availability that
constants give, but you could always combine the two.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
posed, users will need to have some idea of what "live variable
analysis" means, or add dummy assignments, if they want to be sure a
variable is actually local. With a block scoping keyword, they can mark
local variables explicitly, as they would in other languages.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
hat are currently unnecessarily
awkward. I don't think we'd need to add everything at once, just establish
some general design principles.
(I'm honestly surprised that CURLOPT_RETURNTRANSFER, and curl_setopt in
general, doesn't make it onto more lists of the worst parts of PHP.)
Regards,
--
Rowan Tommins
[IMSoP]
($a)=>$b on its own would
collide with array syntax.
I would much rather see "fn" and "function" become synonyms, so that
"public fn foo() {}" is a valid method declaration, and "function() =>
$foo" is a valid arrow function.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ot;, and "function" as a rare "opt-out" or a "legacy version".
2) It does still create a separate scope, it just creates a *nested*
scope, which combines two sets of variables, in a way that PHP currently
never does.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
uot;global", or declaring them "static". It's entirely
in keeping with how scope works in PHP.
>It seems to me that you agree that there is a chance the proposed syntax is
>going to be perceived as better and people will not want to use the old
>syntax anymore and that makes you
often
asking for new features.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
variable now have the new value
var_dump($a, $b);
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
of captures; if that's
really as rare as you suggest, it makes me wonder why we're even bothering.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
some
comments on the PR.
(By the way, the PR you linked is to merge into your own fork's master,
not the actual central php-src repo. Not sure if that was deliberate.)
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https
ent quoteIdentifier only on PDOPostgres; or implement it on PDO as
throwing a "not implemented" exception, with PDOPostgres currently the
only sub-class that over-rides it with a useful implementation.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
s
something like CurlHandle::setRawOption for when users want fine control of the
library, or some really obscure setting.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
by that value will be held until $filter is
destructed, rather than when $guest is destructed
Whether the risk of these side effects is a big problem is up for
debate, but it's wrong to suggest they don't exist.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development
want to ensure that their code is free of
such side effects.
Currently, the only way to do so is to understand the "implementation
details" of which variables will be captured, and perhaps add dummy
statements like "$foo = null;" or "unset($foo);" to make sure of
ut I don't think "fn" vs
"function" is a strong enough clue.
(Making fn and function synonyms sounds like it would have a lot more knock-on
effects that feel very out of scope at present.)
Off the top of my head, I can't think of any, but I admit I haven't
tried hacking
st pointer, to trigger the destructor
unset($some_resource);
// If $some_resource gets captured, it can only be released by
destroying the closure
unset($fn);
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
basis, and doesn't really answer the question of what the
default behaviour should be - especially bearing in mind that any
default should apply to both built-in and user-defined functions.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ht pass "parent::foo", which will change
behaviour in 9.0. It is the application's author who will benefit from
the deprecation notice, so they can pass a different value whose
behaviour isn't going to change.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Developme
have thought of some of the examples you showed in your
earlier e-mail, so I'm genuinely curious what other patterns it's used for.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
used
without actually looking at it.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
a default value. Not receiving a field you expected feels very similar,
so similar behaviour feels reasonable.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ility" with the
version that raises the notice.
(For my thoughts on the rest of what you're saying, see every other
message I've sent to this thread.)
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
than
accepting their misinterpretation and repeating it on this list.
Otherwise, we might as well just promote all deprecation notices to
fatal errors immediately.
I will open a new thread about this later.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing
its own RFC to be voted on. It
doesn't need to say much, just summarise the key points from this
discussion. See https://wiki.php.net/rfc/howto for the steps, and feel
free to send me a message off-list if you want a hand drafting or
proof-reading it.
Regards,
--
Rowan Tommins
[IMSoP]
--
d-process in another.
So, while it probably makes sense for all serialisation errors to consistently
throw, that should be planned for 9.0, and everything that's not already an
exception could raise a consistently formatted E_WARNING in 8.3.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals
; technique it gives "a meaningless result", but doesn't
actually illustrate that result, so I'm struggling to picture exactly
what each algorithm does.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
your point, but those
three should probably be removed.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
int $mode = PHP_DIV_TRUNCATE): int
intmod(int $num1, int $num2, int $mode = PHP_DIV_TRUNCATE): int
Where $mode can also be PHP_DIV_FLOOR, and possibly additional
algorithms in future - the paper linked to on microsoft.com discusses
another three, and implies that there are many more.
Regards,
--
Rowan Tomm
s that like the Symfony example it is
"pretty-printing" existing JSON strings.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
into:
fn() => [ 'dummy' => $dummy ]
which turns into:
function() use($dummy) { return [ 'dummy' => $dummy ]; }
Yes, that is what I meant by "it would be possible for the compiler to
special-case this scenario"; I explained why I think that would be a bad
idea, and suggested an
a user point of view I agree the feature would be useful. It would definitely
need to be behind an ini setting, though, to avoid existing log parsers failing
unexpectedly on the new format.
Regards,
Hi Mikhail,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailin
conds: on / off", not configurable as "enter date format".
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
uld be named to be meaningful in the current scope, not somewhere
they're coming from or going to, but a dedicated syntax would at least
allow that flexibility.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On 19 September 2022 15:24:26 BST, "Olle Härstedt"
wrote:
>Hi internals!
>
>Some editors can guess the domain-specific language inside heredoc, e.g. if
>you do
>
>$query = <
licit in the sense that it is syntax dedicated for that
purpose, in a standard format. If I write <<way to know if "foo" is the name of a language I'm hoping to label, or
just a token which I know doesn't appear in my content; if I write /**
@lang foo */"hello", there's no am
time; if it exactly matches the delimiter,
stop; else, add the line to the file buffer. No actual parsing is required.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
implementations which would all be equally "valid"
according to some use case or opinion, so it's a bit of a quagmire.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
entation
b) There is a better implementation out there, which we should start
using in ext/filter right now
My gut feel is that (a) is true, and there is no point considering what
a new function would be called, because we don't know how to implement it.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Inter
em that needs to be solved and there
are multiple solutions: GitHub issues, corporate/public messengers (Slack?) or
the internals mailing list.
There are certainly ways to approach it; I'm just agreeing with a
previous commenter that this would need to be an explicit part of any
proposal, n
;123u" to say "u123" instead?
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
't support internationalized addresses in their
Unicode form, though, so it won't do for FILTER_FLAG_EMAIL_UNICODE.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
s to these questions, but it
would be helpful to understand people's gut feeling on them, to get a
better idea of what people are imagining.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
mpatible, but
then make users wait before using it in production.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
e whole of ext/filter and making a whole bunch
of new mistakes.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ith a shortage of experts, so I'm wary of adding more
complexity.
I also agree with the previous comment that this would need to be coupled
with some way of monitoring the results - imagine we released an
experimental feature 3 months ago, what do we do exactly to find out if it
needs changing?
Regards,
--
Rowan Tommins
[IMSoP]
extra punctuation, and the
restriction that it comes before the normal visibility keyword:
class Foo {
#[PrivateSet] public static int|string $id;
}
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
code
2. just before throwing a "method not found" error, loop over the list,
autoloading each entry if necessary; possibly at this point, errors would
be raised for naming conflicts and other violations
3. check each in-scope extension method in turn for an "instanceof" match
aga
ld suggest no, to keep things simpler.
(Aside: Reminder that convention on this list is to "bottom-post": quote the
part of message you're replying to, then add your text below.)
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
extension methods higher priority will always be worse for
performance, because the lookups will happen more often. Giving them
lowest priority, just above throwing an error, is effectively free,
unless you're doing something very weird and care about the performance
of errors.
Regards,
->bar()->baz()" has the same "words" as "baz( bar( $foo ) )", just
in a different order.
I do agree that the left-to-right order is nicer to read than the nested
version, but that's largely opinion - it's not actually any shorter.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
en written with
concurrent / asynchronous already "baked in", so are fully ready to take
advantage of it. If you need to rewrite large chunks of your codebase to
use an async-friendly framework anyway, it's less of a leap to switch
language completely.
Regards,
--
Rowan Tommins
[IMSo
towards
simplifying this - e.g. merge "typed" and "untyped" properties by making
"public $foo" equivalent to "public mixed $foo", which would remove the
distinction between "defined" and "initialized".
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
syntax choice is publicly
available, or if there's anyone with inside knowledge we could ask. It
would be good to know if there's a compelling argument the RFC could
mention, or if it was actually chosen for reasons that don't apply to PHP.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals
uot; is that
accessing a property by reference is considered a "set" operation, which I'm
not sure how any implementation could avoid.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
lf or :static which currently fails to
return would be a runtime error, but changing that error into an implicit
return $this could be very dangerous.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
