more consideration to avoid unnecessary bindings.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
extra stack
frame for the callback), and possibly even simpler to compile (no
analysis needed to work out what variables to capture).
Obviously, this doesn't cover all cases where automatic capture would be
useful, but nor is it just a one-trick pony; the Python spec has lots of
example use ca
ements. I'm not sure if use statements are even available at
runtime, but if they were, there would be no way of knowing that the context of
the call to test() should be used, not the context where it's defined.
Regards,
Hi Kevin,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Developmen
e a subtly different feature from void as currently
implemented), we couldn't suddenly repurpose a keyword that's already used. So
if you think "never returns" is something worth representing, it will need a
new keyword, several options for which have been proposed.
Regards,
--
Rowan
useful, but those that do are using "void" exactly as
intended.
Regards,
Oh, and on this point:
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ion syntax would be a much larger bc
break
more suitable for a major version, that I don't expect to pass.
It hadn't even occurred to me to suggest that. I was suggesting the
opposite: if we add something called "println", it should have identical
syntax and behaviour to "print&
t($foo) && somethingElse() ) // does not print
$foo, because the expression passed is actually ($foo)&()
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
. Even worse when multiple
decorators are stacked.
One thing to note is that this kind of implicit jump already happens a
lot with class autoloaders. It is confusing, though.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https
nce
of B.
Are you saying that having the parent::getSomeInt() call fail would be
problematic?
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
that new
DateInterval($period->toIsoPeriodString()) would result in an equivalent
object, rather than discarding special relative values.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
;sayHello" function would give an error at runtime if marked
"noreturn"
- the "redirect" function would run fine if marked "void"
- a function containing "return null;" would fail at compile time for both
- a function containing "return;" would
rate keyword of "noreturn" may well cause confusion. I would
personally prefer the name "never" for this reason.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
f it has a chance
of reaching consensus. I would really like to avoid option C.
[1] https://externals.io/message/95166
[2] https://github.com/php/php-src/pull/2160
[3]
https://github.com/php/doc-en/commit/838941f6cce51f3beda16012eb497b26295a8238
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Inter
::transcode($string, 'ISO-8859-1', 'UTF8'); }
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
859-1) can be used as a polyfill
for correct uses of utf8_encode/utf8_decode, but neither is going to do
the magic trick which people always *hope* those functions will.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
available without any optional packages)?
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
instead, at which
point we're into designing a whole new conversion library. And of
course, once you've got that UTF-8 string, you can't do much with it,
because PHP's native string functions are all byte-based, so you've
basically got to re-invent large chunks of ext/mbstring...
Regards,
--
tin1, and they get converted back.
That code will never do anything useful.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ble to me to design a new function, which is
neither compatible with what we have, nor a reasonable addition on its
own merits.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
trying to get to sleep
that a pure-PHP implementation would be fairly straight-forward because
of the relationship between Latin1 and Unicode.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
base64.
$str = '嵐嵐';
echo strlen(base64_encode($str));
// 12
echo strlen(utf8_encode($str));
// 16
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On 22/03/2021 16:52, Aleksander Machniak wrote:
On 22.03.2021 16:41, Rowan Tommins wrote:
That code will never do anything useful.
I already proved it is useful, regardless of it's name/intention.
You have proven no such thing. If that function is saving you from
errors, it is completely
to write up a separate RFC, to make sure the pros and cons are
fully understood.
Any feedback on that topic, or suggestions for content of that RFC,
please reply in the separate thread, to avoid de-railing this one.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development
t;may be extended" is referring to *who* can make the
decision, not *when* they can make it.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
mited understanding, goroutines are a completely different
concept. Saying "go someFunction()" in Go immediately starts a new
thread-like thing, and doesn't return anything. The runtime manages the
scheduling of the thread, but if you want to get any data out of the
goroutine, you have to pass i
On 15/03/2021 13:16, Matthew Brown wrote:
On Sun, 14 Mar 2021 at 18:09, Rowan Tommins <mailto:rowan.coll...@gmail.com>> wrote:
Are you saying that having the parent::getSomeInt() call fail
would be
problematic?
Yes, that's where this becomes unsound – you can call
haps the default return value would need to be specified separately from the
return type somehow?
Regards,
Hi Hamza,
Welcome to the list, and thanks for sharing this idea.
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
t named constructors are more flexible than overloading
by type (e.g. Foo::fromName(string $name) and Foo::fromCode(string
$code)), and static methods provide a reasonable stand-in for those.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsub
On 27/02/2021 21:17, Nikita Popov wrote:
On Sat, Feb 27, 2021 at 10:12 PM Rowan Tommins
mailto:rowan.coll...@gmail.com>> wrote:
On 27/02/2021 20:05, Nikita Popov wrote:
> If we additionally change it to explicitly print reference
wrappers, I
> believe that deb
That may be a more compelling reason, at least given backwards
compatibility requirements. I don't know how common that is, but it
certainly sounds plausible.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
on back into "dataflow style".
[1] http://joeduffyblog.com/2016/02/07/the-error-model/
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ing this:
class Foo {
public static $bar = new Whatever();
}
Which is absolutely horrible if Whatever's constructor has side effects,
but then most things are going to be horrible if your constructors have
side effects...
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Deve
e I think about it, the more I get the feeling that while this
proposal has some great ideas, it hasn't got the combination quite right
yet.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
tch ( Exception $e ) {
echo $e->getTraceAsString(); // trace is currently incomplete, but
the remaining levels are the trace of the current line anyway, so we can
put the cost here
}
Does that make any sense?
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailin
only makes a difference if the two sources provide
different representations of the same number - "12345" is equal to
"12345" whether you cast both sides to int or leave both as strings.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing
5", "1.") might be used sometimes, but
I'd probably lean against
So, ignoring BC concerns, I would be happy with "numeric string" defined
as "maybe space, maybe hyphen, some digits, maybe a dot and more digits,
maybe space", which I think in regex form looks like
to explain what the refcount *does* tell you. If it stays, it
should probably be labelled more clearly as something most users will
never need or understand.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net
the XDebug version does?
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
query" to mean "parameterised query", which I see a lot.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
}
So although the code is wrong, the user always gets a reasonable error
message. Now replace the database implementation with one that throws
exceptions, and that message will never display; if you're lucky,
there's a default exception handler set; if not, the user will get a
blank white page
xdebug.org/docs/all_functions#xdebug_debug_zval
4: https://wiki.php.net/rfc/deprecations_php_8_1
Regards,
--
Rowan Tommins
[IMSoP]
, but
it would be useful to have a method on the PDO object itself that let
you provide a parameterised string and its data in one go. That would be
safer than using emulated prepares, and (hopefully) more efficient than
using real prepares.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime
tions. I just
wanted to show that "it only happens on error" doesn't mean the impact
is zero.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ion-by-default is a good thing; but if
they have existing error handling, by-passing that handling by throwing
an exception is not.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
r($input) : UUID:random();
Syntax for skipping the is_null/isset on the left would be higher up my
wish list than syntax for skipping the :null on the right.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
pens, I think this is too much
of a minefield.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
n PHP for templating,
this might be somewhere on the list, but after more significant features
like automatic escaping, filter / pipe syntax, etc.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
() instead. Sorted.
Since nobody objected, but nobody seemed to have got round to it yet,
I've raised a PR to remove getdir() and rename the internal
implementation to dir() once and for all:
https://github.com/php/php-src/pull/6855
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP
glance:
$x = [
1,
2,
3,
4,
5
]
// Wait, we're not done yet...
[2];
Short of changing the entire language from semicolon-delimited to
newline-delimited, that's inevitable.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To un
, but am hopeful that it
can be expanded on in future proposals to add a lot of power to the
language.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
and side effects.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
explicit casts are very forgiving.
However, they should probably be a new syntax, because there will be an
ENORMOUS amount of code using deliberately using the existing casts in
lossy situations.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
NOTICE.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
integer
I would however welcome a new function or syntax that either performs a
"strict cast" (producing an error if the cast is lossy in any way) or
checks in advance if a cast *would be* lossy.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Ma
var_export or print_r.
However, I've never used PHPT-style tests outside of PHP internals, and
for anything like PHPUnit or PHPSpec you would normally be testing
against actual PHP values, not any string representation; so I don't
really have any opinion on that scenario.
Regards,
--
Rowan
fferent class
echo $this->b; // allowed: access is to a "delegatable"
property, in a "delegated" context
}
}
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
kes where that intent isn't followed.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
hey're how a
lot of PHP code is developed in practice - as modular libraries linked
by Composer - and I think we could optimise the language for that use
(e.g. applying more cross-file optimisations within a fully preloaded
package).
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ave Derick to comment on the patch itself, since he's the primary
maintainer of both the library in question and the PHP extension that
embeds it.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
an existing class isn't always possible, if it
already inherits from something else. Perhaps the behaviour could also
be available as a trait, which defined stub __get and __set methods,
allowing for the replacement of the internal implementation as you've
described?
Regards,
--
Rowan Tommins
2;" is clearer than "$foo = new stdClass; $foo->bar = 42;"
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
no longer needed to support 8.1, "extends
DynamicObject" could be added. For many code bases, that will be long
before the feature is actually removed - for a private project, maybe as
soon as it's on 8.2 in production.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime D
tra properties after it's created,
you could opt into that using whatever mechanism a named class would
(parent class, trait, attribute, etc; see other thread).
Similarly, the objects created by json_decode or PDO_FETCH_OBJECT only
need the *initial* properties to be dynamic, not to allow pro
tps://wiki.php.net/rfc/static_class_constructor
Although it didn't go to a vote, the proposal was dropped for lack of support.
There's some discussion summarised in that RFC, and you can probably find the
rest by searching for its title on https://externals.io
Regards,
--
Rowan Tommins
[IMSoP]
may not be the best point of reference for
PHP, whose object system much more closely resembles Java or C#.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ing, or a database result
row. The values aren't all of the same type, and you would never want to
apply the same operation to all of them; you will probably initialise
them once, and then access them by name, but don't have the facility to
declare them up front.
Regards,
--
Rowan Tommin
from outer scope when you
create them.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ix not too
painful (including deprecation messages not being too annoying), it will
pay off in the long run.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
dClass" to work, and new code
will expect "instanceOf DynamicObject" to work, so an alias (in either
direction) seems the better compromise.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ongly typed code saying "this
accepts a value of type ErrorGroup, and nothing else".
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
encodings, and only
needing to do a few operations on them. The main problem ext/mbstring
has is that it supports a lot of operations, on a lot of different
encodings, so it's still reusing a general purpose "convert and filter"
algorithm.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Int
ng to here?
Firstly, I'm guessing we're talking about return types here, since
parameters have had types since 5.0, and nullable types since 5.1 with
the "TypeName $foo = null" syntax?
Secondly, do you mean you postponed your adoption of the feature, or was
there some larger issue?
ymbol, rather than giving them names
which only make sense in some contexts.
[1] https://news-web.php.net/php.internals/108347
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
is missing from this implementation.
Since even a single operator interface can't guarantee that all inputs
will have a valid output, I remain unconvinced that implementing 8
different interfaces for the above is any better than implementing one
interface and stubbing the parts that have n
where some of the
operators are only meaningful for a subset of operands. Saying that a
Money object is "Multipliable" would also be "a lie", since multiplying
two Money objects together is a logic error, even though multiplying
Money by a unit-less number is very useful.
ble intersections, and it was a trivial change, then I'd
support it as a "quick win"; but that doesn't seem to be the case.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
retain the type information, and can keep our
values of 1 to 7 (or have no values at all) rather than having to use
powers of 2.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ot familiar with the new enums, the best documentation at the
moment is probably the RFC which proposed them:
https://wiki.php.net/rfc/enumerations
I'm really looking forward to using them :)
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To
s which can now be enums, and fix
constants which are badly named, there won't be enough uses left for
this new feature to justify its inclusion in the language.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On the other hand, if core provides a sane implementation of the parsing
into a generic "bag of key-value pairs" (which PHP calls an "array"),
that would provide a very useful building block for any userland library
to build on.
Regards,
--
Rowan Tommins
[IMSoP]
--
't feel out of place.
Having the function mirror http_build_query() as closely as possible
seems like a good idea, e.g. http_parse_query('foo_0=a;foo_1=b', 'foo_',
';') should return [0=>'a', 1=>'b'].
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing
sagree with that default, but presumably some people think it is a
sensible one.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
what a "resource", they just know the boilerplate to use.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
())`
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
remember that a lot of people reading this have never used Classic
ASP, so don't know what these functions do. Some are easy to guess, but others
less so, such as is_contraction(), is_givenName(), space(), and
str_case_normalize()
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP
ed to PHP.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
mine
I'm not saying I don't *like* these functions, I'm saying I genuinely
don't know what they do.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
perties, even without the target
class's co-operation. However, I think WeakMap (with a helper and a
fallback like above) is probably a superior solution for that, because
adding properties outside the class always carries risk of name
collision, interaction with __get, etc
Regards,
--
Rowan T
example, but I
did at least test it worked. :)
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
many; so far though, nobody has managed to
get enough consensus behind any alternative, as with Larry's RFC that
you mentioned.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ts has indeed changed
in PHP 8.0): https://externals.io/message/92239
* A brief thread about adding a more general interpolation syntax:
https://externals.io/message/111519
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
ses in this
thread with ridiculous hyperbole like "shooting ourselves in the face".
There is no perfect answer, and we should be able to have a rational
discussion about the pros and cons of different strategies.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Develop
an "Iterator" suffix (leading to some quite awkward
names)
* Reflection classes all have a "Reflection" prefix
* Having both "Queue" and "SplQueue", or both "Stack" and "SplStack"
would be a terrible idea, and is a pretty strong argument *
amples which came up last time we had this conversation:
https://externals.io/message/114300#114320
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
t, but not float / Money.
I don't think this kind of type list would be unusual, but it may be a
compromise we have to live with given PHP's type system.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
to work around that
inconvenience.
[1] https://www.iana.org/assignments/http-fields/http-fields.xhtml
[2] https://datatracker.ietf.org/doc/html/rfc3864#section-4.1
[3] https://httpd.apache.org/docs/trunk/env.html#setting
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
, and they are the most portable implementation.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
for the trait to work correctly, not because of some
perceived "correct" use of the trait. This doesn't seem to match your
reasoning for proposing the syntax, so maybe I'm missing something?
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
difference is that right now, you can only overload operators
in an extension, not in userland code.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
it to
a vote.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
501 - 600 of 1094 matches
Mail list logo
