$x = (strict int)$x;
Once converted in that way, you could safely pass to a parameter marked int
in strict mode, so wouldn't need a new pseudo-type.
Regards,
--
Rowan Tommins
[IMSoP]
strong reason to add
?numeric meaning almost the same thing.
> while not having to disable strict_types
It feels a bit like you want to "have your cake and eat it" here - if you want
a loose check and aren't worried about a few unusual values getting through,
why are you
the way they did to the Cats movie
trailer, and may react to this one better. That's fine; we can make a
decision for subjective reasons, but let's be honest and say that.
Regards,
--
Rowan Tommins
[IMSoP]
;< and >> are
first and foremost the shift-left and shift-right operators, and so the
immediate association on seeing them is so obvious it's not worth
mentioning; to others, they just look like a new kind of brackets.
That association might actually be a good reason to avoid that
@Special @@ReallyInt int $var) {};
vs
$f = <> function(<> int
$var) {};
Finally, typing up those examples, it occurs to me that @@ is quite a
"heavy" symbol - it has a large proportion of black (or whatever colour)
pixels - and inevitably a rather "fussy" one.
mn("phonenumber_id", "id", JoinColumn::UNIQUE)
private $phonenumbers;
// Rust-style
#[ManyToMany(Phonenumber::class)]
#[JoinTable("users_phonenumbers")]
#[JoinColumn("user_id", "id")]
#[InverseJoinColumn("phonenumber_id", "id"
ething that is easy to
search for; but how often does the solution to a parse error depend on
exactly what the unexpected token was, so that searching for "Parse
error: syntax error, unexpected" wouldn't give enough of a hint?
Other information currently missing from the message - e.g. co
On 10/06/2020 22:38, Rowan Tommins wrote:
rather than renaming T_PAAMAYIM_NEKUDOTAYIM, we should simply ensure
the user never needs to see it.
I'd like to clarify this slightly: I should have said "beyond renaming
... we should ensure" - I have no particular objection
s, might there be value in a "lightweight reflection" API, which
gave access to things like this without the full power or performance cost
of Reflection?
Regards,
--
Rowan Tommins
[IMSoP]
s discussed in this thread are
raised directly by the parser.
In both cases, I think we know roughly what we'd like to see, so there's
not much else to say until somebody looks into actually doing it.
Regards,
--
Rowan Tommins
[IMSoP]
s:
$newInstance = initialise_object($classDefinition);
$newInstance->__construct(...$args);
return $newInstance;
If a constructor returns a value, it is simply discarded, so a signature of
void would be completely appropriate.
Regards,
--
Rowan Tommins
[IMSoP]
ropriate sub-type), and __construct() was marked ": void", and
leave the rest of the logic to the generic code for handling those
declarations.
Again, I would be surprised if any style guide would forbid writing
"getIterator(): Traversable" just because the check is alread
with complex rules of "it's
optional except when it's not", which I'm personally not a fan of.
Regards,
--
Rowan Tommins
[IMSoP]
add the extension with only the
new PHP\* names, and provide a userland polyfill for users upgrading
from the PECL extension?
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
nny weather, fully expect to have a
patch (and, if deemed necessary, RFC) in plenty of time for 8.0.
I intend to post a new thread with examples of old and new messages once
I've finalised the details.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Develo
ot many
offering to work on it. I also appreciate that I hadn't provided any
public updates on my progress, and what hurdles needed to be over-come.
But you did know I was working on a patch, so the simple solution would
have been to ask me before opening the vote.
Regards,
--
Rowan
a vote.
Any other feedback is welcome.
(As an aside, the other commonly requested change was to include column
numbers; this appears to be feasible, but definitely more complex, and
with potential performance trade-offs. I hope to re-visit this later.)
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
nd re-add them.
The consistency should aid anyone trying to parse the error message, since
the pattern /unexpected ([^"]+) "(.*?)"/ will always give you a token name
(even if just 'token') and its content.
I can re-visit that part if you feel strongly, though.
Regards,
--
Rowan Tommins
[IMSoP]
ommon name of the offending
> token was spelt out, something like: unexpected double quotation mark.
>
That would be a reasonable special-case; theoretically, the same would
apply for a lone single-quote, although I think the parser happens never to
see that as a separate token.
Thanks for the feedback,
--
Rowan Tommins
[IMSoP]
ls/init.md#detailed-design
[2] https://wiki.php.net/rfc/object-initializer
[3]
https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/readonly
[4] https://devblogs.microsoft.com/dotnet/welcome-to-c-9-0/#with-expressions
--
Rowan Tommins
[IMSoP]
On 29/06/2020 17:21, Marco Pivetta wrote:
Hey Rowan,
On Mon, Jun 29, 2020, 18:19 Rowan Tommins <mailto:rowan.coll...@gmail.com>> wrote:
On Mon, 29 Jun 2020 at 16:44, Marco Pivetta mailto:ocram...@gmail.com>> wrote:
> property accessors seem to perpetuate the bad
would behave before and after, and what updates the user would
need to make.
Regards,
--
Rowan Tommins
[IMSoP]
with a new column showing those
additions: https://rwec.co.uk/x/php-parse-errors/comparison.html
If there's no other comments or objections, I would appreciate if
someone could merge this in so it can be tested in the next alpha :)
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
I strongly recommend searching for previous discussions and proofs of
concept before diving in.
[1] https://wiki.php.net/rfc/userspace_operator_overloading
[2] https://externals.io/message/105589
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
to be spent naming things - quite the contrary, it will mean
more time is wasted debating every case.
It's worth stressing that naming conventions are not new - we've had them
for global functions for many many years. We may talk about "putting things
into namespaces", but PHP's namespaces really are just names, so this RFC
could easily be called "update naming conventions for classes".
Regards,
--
Rowan Tommins
[IMSoP]
On Thu, 9 Jul 2020 at 18:14, Derick Rethans wrote:
> On Thu, 9 Jul 2020, Rowan Tommins wrote:
>
> > And yet we have repeatedly had discussions about whether this or that
> > feature should or shouldn't be prefixed with a namespace. If you think
> > the correct answ
more open to a version of the feature that was opt-in at the
definition site? Then your example could swap the hand-rolled documentation
and validation in "fromArray" for a fully typed signature in
"fromNamedParams", and the only compatibility promises would be ones
already made by "fromArray" anyway.
Regards,
--
Rowan Tommins
[IMSoP]
ams
The only other alternative I know of is the builder pattern
($builder->withFoo($foo)->withBar($bar)->withBaz($baz)->build()), which at
least makes the boilerplate scale linearly rather than exponentially, but
is still going to require dozens of lines of code to achieve what named
parameters can do with one.
Regards,
--
Rowan Tommins
[IMSoP]
would be an interesting solution to the "modified clone" problem of
full immutability (how to implement withFoo methods), since any "frozen" object
could be cloned to get a mutable copy, which would be frozen before passing on.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
It also has much lower performance impact. Even the automatic form can probably
be performed by the compiler - e.g. if "new" was called in this function,
insert a call to "freeze" before the first time the object appears as a
function parameter
Regards,
--
Rowan Tommins
[IMS
t mutate it after
initialisation because you can't guarantee yours is the only reference) or an
optimised copy-on-write (mutate if you happen to have the last reference,
otherwise clone). It would be better for the language to implement those in a
user-friendly way than exposing the implemen
turns out we already have a
construct for doing that: function signatures.
If the input is an actual array or object coming from "outside", you're
probably going to want a more extensible validation system anyway. Those are
really hard to design, and probably best left to use
ou're trying to catch here
is programmer mistakes, not unexpected run-time behaviour.
Regards,
--
Rowan Tommins
[IMSoP]
id in PECL)? Or
should the policy be that there are no namespaces used by the core?
Regards,
--
Rowan Tommins
[IMSoP]
ask you the same question I have asked others, but without much
response: would you vote Yes to an alternative proposal to officially adopt
a policy of _never_ using the PHP\* namespace, to eliminate future debates
about when to use it?
Regards,
--
Rowan Tommins
[IMSoP]
d ever
needing to skip parameters, it would be great to see some ideas to make
those alternatives easier. For instance, if you think parameter objects
plus the builder pattern is the right way to go, how can we reduce the
boilerplate currently required to define the builder class?
Regards,
--
Rowan Tommins
[IMSoP]
nk the "PHP"
in its name is a " fake namespace" at all - it is an object representing a
token of PHP source code, and thus a PHP token. Even inside a namespace,
there would be an argument for giving it that name.
Regards,
--
Rowan Tommins
[IMSoP]
s.io/message/110004#110025 They don't
make a particularly good comparison for PHP.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ed by adding parentheses
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On 25/07/2020 16:26, Chuck Adams wrote:
On Fri, Jul 24, 2020 at 1:32 PM Rowan Tommins wrote:
If anything, I would argue for making both of these into errors, if
that's possible. I think the biggest risk with this kind of change is
not existing code relying on the old behaviour, it is
ls.io/message/110004
[4] https://externals.io/message/110910#110961
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
thing we should bolt on in a hurry just to solve an issue with named
parameters.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
/pull/5899
I realise it's now rather last-minute for 8.0, so if anyone thinks it
should have more careful thought, or an RFC, it will have to wait. If
there are no objections, though, it would be nice to have it merged
before the freeze.
Thanks,
Rowan
On 21/05/2020 22:53, Rowan Tommins
tening for
Transfer-Encoding, because it's increasingly rare for a server to actually
honour the 1.0 spec.
My main motivation for the change is that if someone was writing the
feature today, I don't think it would occur to them to default to 1.0, and
I think _new_ users would be less surprised at needing to opt into 1.0 than
into 1.1.
Regards,
--
Rowan Tommins
[IMSoP]
that various HTTP 1.1 features are enabled in our
client code by default suggests that is frequently not the case.
Regards,
--
Rowan Tommins
[IMSoP]
s far as I have been able to tell, the client code now complies
with the spec for HTTP 1.1, although I struggled to find a list of
minimum capabilities.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On Wed, 29 Jul 2020 at 03:31, Ryan Jentzsch wrote:
> https://phil.tech/2013/wtf-is-t-paamayim-nekudotayim/
https://3v4l.org/guXbl#v800alpha3
You're welcome.
--
Rowan Tommins
[IMSoP]
ficult, would
it suffice to make the () mandatory (i.e. @@Deprecated() rather than
@@Deprecated)? The rules for what could appear between @@ and ( are pretty
simple, and finding the correct ending ) should be pretty much the same
effort as finding the correct ending ], since both can occur in matching
pairs inside the argument list.
Regards,
--
Rowan Tommins
[IMSoP]
ould not enjoy going through
every Composer package in my vendor directory, checking for or supplying an
appropriate patch, and then waiting for a tag or forking to create my own.
Regards,
--
Rowan Tommins
[IMSoP]
@(Foo)
@[Foo]
@[Foo]@
With complex parameters:
@@Foo('hello @@ world', (1+2)*3)
@(Foo('hello @@ world', (1+2)*3))
@[Foo('hello @[ world ]', [1,2,3])]
@[Foo('hello @[ world ]@ again', [1,2,3])]@
Regards,
--
Rowan Tommins
[IMSoP]
nd removal process.
Opportunities that might, depending on a whole bunch of other factors,
come in PHP 10.0 or 11.0 are probably not a strong argument for a syntax
option.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, vi
On Thu, 6 Aug 2020 at 07:40, Derick Rethans wrote:
> On Wed, 5 Aug 2020, Rowan Tommins wrote:
> > The confusing thing about this argument is that as soon as they have
> > arguments, attributes will have an ending delimiter _whatever_ syntax
> > we choose, because nob
ide
listed it as "discouraged", PSR-1 / 2 / 12 don't mention it at all.
I agree that it is probably rarer than //... and /*...*/ but let's avoid
unnecessary hyperbole.
Regards,
--
Rowan Tommins
[IMSoP]
" seems to be rather subjective; is it the
"@" that makes it familiar? the lack of extra brackets? I'm not sure it's
fair to boil this down to a straight yes/no.
* "Tokens Used" seems to be an implementation detail, with no explanation
of why this would make a difference to anyone's vote.
Regards,
--
Rowan Tommins
[IMSoP]
GOLPLEX = 10 ** GOOGOL; // type of result inferred from
existing constant
function waste_time(BigNum $iterations = GOOGOLPLEX) { ... }
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
static method, and some private static
variables, since right now we don't think of a function as "belonging
to" a file in the same way it would belong to a class.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
/wiki.php.net/rfc/named_params#vote
[4] https://externals.io/message/110910#110961
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
lready has,
which in my view make this new feature unnecessary.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
use I think
the current syntax is perfect, but because I don't think this RFC makes a
good case for a revote, and strongly suspect it will just be another beauty
contest.
Regards,
--
Rowan Tommins
[IMSoP]
other syntaxes?
To avoid repeating myself, here are the previous posts where I elaborated
on this question:
* https://externals.io/message/111312#111342
* https://externals.io/message/111312#111354
Regards,
--
Rowan Tommins
[IMSoP]
On Mon, 10 Aug 2020 at 14:56, Benjamin Eberlei wrote:
>
> On Mon, Aug 10, 2020 at 3:40 PM Rowan Tommins
> wrote:
>
>> The question asked was that _if the parentheses were made mandatory_,
>> would
>> this provide the same benefits ascribed to the other syntaxes?
led), but the input is casted to 0 and thus producing
unexpected behaviour if the user is not aware of the current method
prototype.
Unless there are problems with the implementation, this seems like a
straight-forward win.
Regards,
--
Rowan Tommins
[IMSoP]
t use buttons to the right of the letters, although #[] is
the only one that doesn't need any use of shift. Which mostly just goes to
show that pretty much any punctuation will be hard to type on some layouts
and easy on others.
Regards,
--
Rowan Tommins
[IMSoP]
at like every other factor discussed, this is
basically a subjective feeling, rather than anything substantial.
Regards,
--
Rowan Tommins
[IMSoP]
ely no idea which is more common, and what the
impact would be.
My vote, if I had one, would remain under "No" for this re-vote. There
seems to be no reason to allow this vote, but not allow another one next
week with a new suggestion, and nothing objective to choose between the
syntaxes.
Regards,
--
Rowan Tommins
[IMSoP]
d be useful if it was a re-cap of
arguments discussed in prose elsewhere, but it is not on its own a good
source of information for making a decision.
Regards,
--
Rowan Tommins
[IMSoP]
t last one has a small chance of matching something like "$foo =
$bar<> has a small disadvantage here, but it's also been
thoroughly rejected in a previous vote, and seems unlikely to suddenly make
a comeback.
Regards,
--
Rowan Tommins
[IMSoP]
attributes, or always use fully-qualified names in attributes...
Regards,
--
Rowan Tommins
[IMSoP]
ich as others have pointed out are similar to
visibility or scope modifiers - anywhere that could be an attribute will be
parsed as one, not as a statement, comment, or whatever else, so some code
changes meaning, and other code becomes a syntax error.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
cho render_html_string(
stringParts: [ '<', '>Hello ', '' ],
expressions: [ $tag, $_GET['name'], $tag ],
modifiers: [ ['raw'], [], ['raw'] ]
);
It will take a while to figure out the details, but I think a powerful
feature
'orange',
3 => 'banana',
4 => 'caramel',
];
$selected_option = $options[ $_GET['id'] ] ?? 'vanilla';
Casting between arrays and objects is a whole separate issue, and changed
in PHP 7.2; the RFC explains the issues quite well:
https://wiki.php.net/rfc/convert_numeric_keys_in_object_array_casts
Regards.
--
Rowan Tommins
[IMSoP]
On Mon, 17 Aug 2020 at 16:21, Matteo Beccati wrote:
> Hi Rowan,
>
> On 21/05/2020 23:53, Rowan Tommins wrote:
> > d) Support "chunked" transfer encoding (RFC 7230 Section 4.1)
>
> FWIW, I've just been hit by https://bugs.php.net/bug.php?id=47021 in a
> SOAP
ification than being able to write $"Hello
#{Foo::bar()}\n" rather than "Hello " . Foo::bar() ."\n"
Regards,
--
Rowan Tommins
[IMSoP]
ding someone
else to; if nothing else works, you might be able to pay someone to do it.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
general case is this:
array_map(fn($x)=>$x[array_key_first($x)], $rows)
Of course for a list-style array like the example shown, it can be a lot
simpler:
array_map(fn($x)=>$x[0], $rows)
Regards,
--
Rowan Tommins
[IMSoP]
ng value, which AFAIK is not possible with
"exists".
Regards,
--
Rowan Tommins
[IMSoP]
ngside the existing on-demand compilation; it could be entirely manual
as a separate tool; or it could be combined with a new, manually executed
compiler or transpiler. I believe there is precedent for all of these
approaches.
Regards,
--
Rowan Tommins
[IMSoP]
at_CSV
That leads me to think that if we do want "module"-level features - be
it internal classes, internal properties, or module-level declare()
settings - we need a way for the user to define that separately from the
fully-qualified namespace.
Regards,
--
Rowan Tommins (né Collins)
ccessible in "Acme\Frobulator"
and all its sub-namespaces
}
[1] https://kotlinlang.org/docs/reference/visibility-modifiers.html
[2] https://www.tutorialspoint.com/scala/scala_access_modifiers.htm
[3]
https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/acce
opics with a bit
more thought than this - being able to say "I've looked into improving
X, and it seems possible that it could work like Y, with possible
problem Z; should I pursue the idea?" is going to get a more favourable
reaction than just "wouldn't you like X?
gic happening here" seems sensible.
Presumably we could also allow grouping of nested attributes such that this:
#[Foo(#[Bar, Baz]) class X ...
Would just be equivalent to this:
#[Foo([ #[Bar], #[Baz] ]) class X ...
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
how stable we can (or want to) make the VM, so
these files will never be as portable as a Java class file or .Net assembly.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Cache already provides that for PHP.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
m_id" does not match. An E_STRICT is completely inappropriate
for this scenario.
Regards,
--
Rowan Tommins
[IMSoP]
the original
source paths.
Regards,
--
Rowan Tommins
[IMSoP]
rthogonal to the other features - my
impression is that actual expression length (feature 3 above) is more of
a pleasant side-effect than a top priority for most people.
I would personally prefer the "fn()=>" syntax to carry on meaning "this
is an expression elevated to functi
t that
code would look like, though, since it's always necessary to filter the
list of attributes to exclude those from other libraries.
Regards,
--
Rowan Tommins
[IMSoP]
seeing the RFC if Nuno decides to proceed with it,
because I am much more interested in how it will affect *users* of PHP
than the technical details visible in the PR.
[1] https://externals.io/message/98045#98209
[2] https://wiki.php.net/rfc/throw_expression
[3] https://wiki.php.net/rfc/match_
happen *every
year*, not just every 5 years. I'm concerned that people may consider "PHP
7" to be "current", even though both 7.0 and 7.1 are now EOL, and that the
same will happen with "PHP 8" in a few years' time.
Regards,
--
Rowan Tommins
[IMSoP]
y is useful precisely because it's "batteries included", like
the password_* functions. I'm not that familiar with the hash functions, so
can't really comment whether I would expect them to be usable "out of the
box" or just as primitives for a higher-level wrapper.
Regards,
--
Rowan Tommins
[IMSoP]
y to
all" (which accumulates CCs), and no "reply to list" (which would pick up
the list address from an appropriate header and ignore everything else).
Regards,
--
Rowan Tommins
[IMSoP]
lt > 42 ) ...
vs
if ( $foo->updateStream($bar) > 42 ) ...
Regards,
--
Rowan Tommins
[IMSoP]
hey
would be recursively instantiated by newInstance(), etc).
Regards,
--
Rowan Tommins
[IMSoP]
nextBaz) {};
// Extend this to accept an array spread? Means all properties have to
have the same visibility and type, or default to "public mixed"...
$data = ['foo' => 42, 'bar' => 84, 'baz' => 69]; // dynamic data, e.g. a
DB result set row
$o
maybe we could make "function" and "fn"
synonyms everywhere, i.e. make both "$double = function($x) => $x *2;"
and "$double = fn($x) use ($x) { return $x *2; };" valid. I'm not sure
if that's desirable, or even if there's a reason it can'
. The only downside is a slight
inconvenience for cases where you want an argument of exactly one nested
attribute, but I don't know how common that is.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ue;
}
return $result;
}
you can write:
interface DynamicDBItem {}
function getFromDB(...): DynamicDBItem {
$result = new class implements DynamicDBItem {};
foreach ( $this->blah() as $column => $value ) {
$result->{ $column } = $value;
}
On 23 October 2020 21:14:49 BST, Mike Schinkel wrote:
>> On Oct 23, 2020, at 2:33 PM, Rowan Tommins
>wrote:
>>
>> I don't follow; is the resulting JSON different if you cast to
>object, or is there some other reason you prefer an object over using
>an assoc
e any that explicitly
require them as input.
For userland code, I'm not aware of any scenario where "new stdClass"
could not be replaced by "new class {}", or why a polyfill would be any
more than "if ( ! class_exists('stdClass') ) { class stdClass{
e-visiting it this close to
8.0 availability.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
401 - 500 of 1172 matches
Mail list logo
