stop you getting E_NOTICEs.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
the same as
> $var = @$_GET['test’];
No, that would be a syntax error.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
::getType
This seems to be the cleanest. Perhaps we should just call these “parameter
types” and “return types”, or “type declarations” in full?
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
.
var_dump($_GET[‘foobar’] ?? 3);
?? also has the advantage of being shorter.
> Also, not much sure about a '??=', perhaps it should be a followup RFC
> should '??' be accepted.
It’d make sense to do it within this RFC if possible. If it seems too
controversial, it
php_config.h and to
> validate IDN only if ICU is present.
>
> What strategy is preferred?
Perhaps add a new filter that covers normal URLs and IDN ones? I just imagine
it might cause problems if suddenly IDNs are accepted, if there is a backend
which can’t handle them.
--
Andrea
s never used. This feature makes code
that does, for example, a linear search nicer to read.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
happy to create a thread for
> the other scenario later on, and we can discuss the python style there
> instead.
I’m bringing it up because I think we’re only going to end up with one feature
or the other, and I think Python’s behaviour is more useful.
--
Andrea Faulds
http://ajf.me/
does C# have one, it may be a pain to
implement, and I’m not sure we need it.
Thanks!
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
vote. I think doc and
peck contributors are as valued as any other contributors. However, people with
no karma whatsoever (a blank people.php.net page) voting irks me.
Thoughts?
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
e enough contributions to earn either karma or community rep status
should be allowed to vote. My problem is people with neither.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
necessary? I think this could
work.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 14 Sep 2014, at 23:23, Andrea Faulds wrote:
> Good evening,
>
> This RFC has been put to a vote. It starts today (2014-09-14) and ends in a
> week’s time (2014-09-21).
>
> https://wiki.php.net/rfc/integer_semantics#vote
>
> Thanks!
The vote has now closed. Th
> On 21 Sep 2014, at 03:52, Xinchen Hui wrote:
>
> Hey:
>
> it should be closed tomorrow, not today.
It's the 21st in my timezone. I started the vote at 2am on the 14th and it's
now 4am on the 21st. I don't see a problem.
--
Andrea Faulds
http://ajf.me/
implemented” parts we have), than some shiny, shiny array-style
> access to NodeList items. That said, people do like the shiny, shiny.
I think this particular request is harmless. Note that this works in JavaScript
as well.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Deve
forgot I’d opened the vote at ~23:00
and not ~02:00. Unfortunately, I realised my mistake after merging the patch.
This was definitely not intentional.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
view?
We already use ICU in many places, so it's more likely to be available and
people can get IDN support "for free". I suppose, then, the license isn't an
issue.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I was lucky that one
more person voted before I closed it. I made an honest mistake and closed it
too early.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
restart it?
If we’re going to reopen or restart, I’d prefer to completely restart it than
to just reopen it. A clean slate.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
s.
An 8:8 vote is not a majority, no, but a 9:8 would be a 50%+1 majority.
A 16:8 vote *is* a 2/3 majority. 2/3 of people have voted in favour, with 1/3
against. It’s a very narrow one, but so far I’m yet to see anyone say it should
be 2/3+1 and not plain 2/3.
--
Andrea Faulds
http://ajf.me/
On 22 Sep 2014, at 12:32, Derick Rethans wrote:
> On Sat, 20 Sep 2014, Andrea Faulds wrote:
>
>> Perhaps I’m being unfair and overthinking things, but I wonder if it
>> is really fair for people who have no karma, i.e. not contributors to
>> the documentation, extensi
Good evening again,
Here’s a new RFC: https://wiki.php.net/rfc/zpp_fail_on_overflow
Thoughts appreciated, as is help with the patch, though I can probably manage
on my own.
Thanks!
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe
if, for the UString class krakjoe is working on, it could
implicitly convert.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ays.
If we’re re-opening things, let’s just hold the vote again, rather than
extending the existing vote.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
t; (common situation in proxy/glue libraries, etc. - they'd be completely
> fine with garbage in - garbage out) but need special code to handle
> situations where the function fails to run altogether.
How do these libraries you speak of handle passing other types of arguments
that fai
''), etc) by
> the surrounding code.
Right. It’s not an E_RECOVERABLE_ERROR, you’d just get an E_WARNING.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ettype() is still going to return “object” not “resource”, but
I suspect people are more likely to use is_resource().
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
) everything else leads to issues.
I’m not sure this is a fair example. Don’t classes usually implement a
`__toString()` that is based on the data they contain? If they don’t, I’m not
sure they’re useful for indexing anyway.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
d much prefer to just
support __toString here. I think users are smart enough to understand that PHP
arrays only have string or int keys, so it casts to a string.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
c function __toKey() : int | string {}
Psuedo-code, since you can’t have multiple return types. I think it’s a better
name than __hash (fits well with __toString IMO), and this way we can support
integer keys too, where that makes sense.
--
Andrea Faulds
http://ajf.me/
--
PHP Inter
On 24 Sep 2014, at 21:46, Johannes Schlüter wrote:
> I don't think there is a clear leader on usage of __toString(), for some
> it is a debugging feature, for some a "normal" operation.
If people want debugging, there is a method specifically for that, __debugInfo.
ch_value);
>break;
> }
Incredibly, some brave soul has gone back in time and already implemented this,
when none of us was looking!
switch($switch_value = some_expression()) {
...
}
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
NT_MAX.
No it won't. Normally it truncates (module), only some functions cap.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
nds here.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 26 Sep 2014, at 11:48, Andrea Faulds wrote:
> On 26 Sep 2014, at 11:46, marius adrian popa wrote:
>
>> Maybe we need an official stance about shellshock
>
> Do we? As I understand it, this isn’t a PHP-level vulnerability, and I’m not
> sure there’s much we can r
ould be in favour of removing string support, but I don’t want to
remove ArrayAccess. There’s no good reason to get rid of it.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
to vote against string support, but in favour
ArrayAccess support.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
his note to RFC.
>> May be it'll change mind of some voters :)
>>
>> also add a link to your patch.
>
> Please do not :) Enough mess with RFC changed while being voting on.
Yeah, that’s a pretty big change. I wouldn’t vote how I did if it meant
affecting ArrayAc
> On 20 Sep 2014, at 00:34, Andrea Faulds wrote:
>
> I’ve put the Null Coalesce Operator RFC to a vote:
>
> https://wiki.php.net/rfc/isset_ternary#vote
>
> It is a 2/3 majority vote and ends in a week’s time on 2014-09-27.
By 31 votes to 3, the RFC has passed and voti
y user would be able to chose between compatibility and safety.
I really, really don’t like this idea. PHP needs less INI-dependant behaviour,
not more.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
r character could be added,
basically to match what l currently does.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
lot of PHP
users need this, it shouldn’t be in core.
> Also, any new functionality introduced to PHP would always be new, young
> and caring maturity.
What does that even mean?
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
s, and how does it handle null? How is
inheritance/interface compatibility dealt with?
Thanks!
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
it.
Huh, why is the keyword choice not part of the vote? So, if people vote for it
with ‘or’, you could change it to something completely different?
I don’t think that’s normal procedure.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
avour of it last time
we talked about it. I’d certainly be in favour of allowing `function` to be
omitted when there’s a visibility specifier, like so:
public foo() {}
public static foo() {}
Easy to implement, too. What are the list’s thoughts? I don’t think it really
hampers readability much
> segfaults
> - - php + gmp + odbc + freetds => se'gfaults
>
>
> The simple proposal will be to drop the mp_set_memory_functions call.
>
> Any other (better) idea ?
Can't we just make gnutls use its own (statically-linked?) gmp instance?
I'd rather not
ere’s no need to deprecate it any time soon. The variadics
syntax is merely a nicer alternative. We should not force people to rewrite
existing code to use it. There is absolutely no need to get rid of
func_get_args.
I would vote against any such proposal, and I hope others on the list would
join
values. It’ll lead to a segfault. PHP must bail out
immediately when this happens to prevent segfaulting.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ely suspend usage of the
previous one in such a short timespan (especially given how few people will
have moved to 5.6 by then) for a non-security fix.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
were it to ever
make it into master. It sets gmp to use emalloc as its allocators (much like
ext/gmp). This means it obeys memory limits. Being able to circumvent the
memory limit and DoS the server by doing a stupidly large exponentiation would
be quite scary.
--
Andrea Faulds
http://aj
be appreciated.
Thanks!
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
hem changing to long strings and I
> don't see how GMP fixes that?
What you want is 64-bit data handling. This is arbitrary-bit data handling.
It’s not a “wrong approach”.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
er not a variable one …
“Bigints” typically refer to arbitrary-size integers, that is, their size is
bounded only by the amount of RAM available.
I don’t know what you think a “bigint” is, but it’s different to everyone else.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Dev
On 10 Oct 2014, at 13:08, Remi Collet wrote:
> Le 10/10/2014 12:57, Andrea Faulds a écrit :
>>
>>
>> Can't we just make gnutls use its own (statically-linked?) gmp
>> instance?
>
> Not an option.
> As gnutls change will imply downtream change,
> an
tion. We should just fix the
implementations.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ues.
Though I’m not sure why you’d need to.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
nstants too would
be good, but I’m not sure if they’re actually implemented as aliases (they
might just be copies).
2. Shouldn’t it return fully-qualified class names beginning with a backslash?
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubsc
On 13 Oct 2014, at 15:14, Marco Pivetta wrote:
> On 13 October 2014 16:12, Andrea Faulds wrote:
> 2. Shouldn’t it return fully-qualified class names beginning with a backslash?
>
> When in string context, we are typically always talking about FQCNs, so the
> leading backslas
are just ints.
Making it optional destroys most of the benefits of the RFC. Instead of
reducing platform differences, it adds a massive new one. Now developers have
to check whether or not bigints are enabled and have two different code paths.
That's much worse than the status quo.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
gt; Is there a reason why we don't want this or is it just that nobody has
> actually written it yet?
$_GET and $_POST are really misnomers. $_GET is query string parameters, $_POST
is request body data.
We should just put the request bodies for all requests, not just POST, into
$_POST.
-
al vars with such misleading ... meanings.
Let’s add $_REQUEST_BODY and $_QUERY_STRING and make them aliases of $_GET and
$_POST then. Because they’re aliases (by-reference superglobals), there’s no
additional memory consumption, but we finally have saner names.
--
Andrea Faulds
http://aj
nse, but
isn’t too long:
* $_QUERY - query string parameters
* $_BODY- request body parameters
* $_REQUEST - query string and request body parameters
Makes more sense than $_GET and $_POST.
Any objections?
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mail
method can have. Similarly,
by using $_BODY, it’s clear it’s about request body parameters, which any
method can also have.
Sure, all existing code uses $_GET and $_POST and they won’t go away any time
soon. But we would have saner names that people writing new code can use.
--
Andrea Faulds
uld add a UString class to PHP for Unicode strings. This would make
Unicode text manipulation much easier than it is now. And both internal and
userland code which accepts strings would already be compatible as it has a
__toString method, but new code could also choose to accept UStrings direc
think that’s widely used, and there are only two formats that come after
the question mark. If you really need the raw string, it’s in $_SERVER anyway.
So that’s not really a problem.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit
ectively, right?
That’s my idea, yes. They’d be implemented essentially as by-ref assignments
internally.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
t Rquest - Content-Type:
> application/json?
> It is mandatory for RESTFull.
This has been discussed before. I’m not sure it’s a good idea.
json_decode(file_get_contents(‘php://input')); isn’t that bad.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Maili
ou
> suggested that?)
So, we currently parse multipart and url-encoded request bodies for POST and
put them in $_POST. I'm just thinking there's no good reason not to do so for
any other request method. However, to avoid confusion, we alias it to $_FORM so
it's clear it's no
he code existing now doesn't need bigints, and even in the future
> most code won't need it. But for some code it would just work like
> before, only with unlimited range now.
No, but existing code does have to handle float overflow. If you allow that to
optionally be int overflow, you now need to worry about handling both.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ne,
they’re IS_LONG internally, and on 32-bit machines they’re IS_BIGINT, but the
user doesn’t need to worry, they both act the same.
Assuming I actually get round to updating the DB drivers.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
C is to make integers completely consistent across
platforms and to remove the need to worry about overflow. Adding optional
overflow to GMP means you still have to worry about it. It doesn’t solve
anything. You can already use GMP for applications which explicitly need to use
large numbers
s an integer key, otherwise a string key.
So the handling would actually be the same as now for array keys.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ers completely consistent
>> across platforms and to remove the need to worry about overflow.
>
> Which does not change with my proposal.
No, it does: There are now integers, and objects that represent large integers,
which behave differently.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
l”, but
it does solve your use case.
If you really want to go and add 64-bit emulation to 32-bit builds, be my
guest. But nobody’s gone and done that.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
not just pretending it's a really big
> version of ASCII.
Sure. But just handling code points safely is hard enough as it is. This
handles that. It doesn’t handle characters, sure, but it’s a start. And for
many applications, you do not need to handle characters.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
as an alternative if the current RFC is rejected on
> complexity or licensing grounds.
As all bigint ops are abstracted, you could modify the patch to implement
64-bit integers if you wanted. Granted, they’d be unnecessarily allocated their
own memory, but it’d be doable.
--
Andrea Faul
; here.
The point is the degree to which they can act the same. Objects can only go so
far.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
script startup) rather than call-time.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>> --
>>> PHP Announcements Mailing List (http://www.php.net/)
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> On 10 Oct 2014, at 22:33, Andrea Faulds wrote:
>
> The RFC can be found here: https://wiki.php.net/rfc/bigint
>
> The patch is, as I mentioned, incomplete. Additionally, there are quite a few
> matters left to be decided (see Open Questions). However, I think I should
&
Good evening,
I am presenting a new RFC to add a set of three functions to do validated casts
for scalar types:
https://wiki.php.net/rfc/safe_cast
Please read it.
Thanks!
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
afe" as in
> "security", but only "safe" as in "no data loss”.
Right.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
t, I don’t like that idea
much. It doesn’t chain very well… and would it fail a strict type hint, if we
added that? Even if it somehow did, I don’t think it is a good idea. Since I
don’t think is_bool will happen, there’s also no real need, either.
--
Andrea Faulds
http://ajf.me/
--
PHP Int
be just as convenient as an
explicit cast, so that doing the safer thing (failing on garbage input) is not
any more difficult. The hope is that the lazy developer will use is_int()
instead of (int) when they need to explicitly cast, and avoid the problems of
the latter.
--
Andrea Faulds
http://a
d but morally equivalent to returning null. But I'm not
> aware of any language which specifically returns false.
JavaScript returns NaN here and C sets errno to an error value. PHP uses FALSE,
in some respects, like JavaScript uses NaN.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ck the return value anyway and would get 0
> as the result of false-to-int conversion, thus making the whole exercise
> pointless anyway :)
Not quite. With strict type hints, FALSE would fail for an integer parameter.
Even without them, this still makes validation more straightforward. I su
oday if I remember. It shouldn't be any slower than
master, though. All it does is change what we do in our usual overflow checks,
which we already had. Now, once you've overflowed and got a bigint, obviously
they're slower than floats. However if you need floating-point perf
but should be less of a problem
> I'd imagine.
I think we should reserve some way to do Unicode strings. I’d want u”foo”, but
we’re not adding literals, so u(“foo”) it is.
Also, bear in mind that namespaces mean you can still have your own u() if it’s
in your namespace (\u).
--
Andrea Fa
API more useful.
On that note, ->charAt ought to be ->codepointAt to avoid being misleading.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ass. Make array-like indexing with [] be by code points as you
may be able to do that in constant time, and because there might be multiple
approaches to choosing graphemes. Have ->codepointAt(), but also
->nthGrapheme() or something like it. There’s no need for grapheme versions of
all functions, but others would need them.
Though your approach has its own merits.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
uggested on Twitter was by Matt Parker, who suggested that I add an optional
2nd argument. Without the argument, it throws an exception. With an argument,
it returns that value (as a default) instead of throwing an exception.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runt
> On 21 Oct 2014, at 22:01, Rowan Collins wrote:
>
> On 21/10/2014 02:17, Andrea Faulds wrote:
>> There isn’t a lack of a value, there’s no value.
>
> You might want to consider re-wording that. It comes across as rather an
> oxymoron…
Oh dear, I repeated myself accid
val, floatval and strval. I think people will notice
the fact they were introduced in PHP 7 and the fact they’re not aliases of
those, and perhaps realise they’re different. If they just followed the
“standard conversion rules”, why would they exist given the existing functions
for that?
--
Andrea Fauld
new rules are definitely becoming major part of the language, not an
> implementation detail of some random function like str_pad.
No, they’re just a set of new validation functions.
> Saying "oh, we just add it like a random function and _only then_ we'll
> make it an opcode an
d, or will run ever-so-slightly faster.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
e existence of ext/filter given it has
FILTER_VALIDATE_INT, a “primitive for handling type conversions”?
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
t the latter has slightly different rules, is
shorter, and if some people (possibly me) get their way, might throw an
exception.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> On 22 Oct 2014, at 21:12, Andrea Faulds wrote:
>
> I ran the script several times, then took the results and put them into Excel
> to produce the above table with its averages.
>
> So common scripts are either unaffected, or will run ever-so-slightly faster.
Just to be c
er key types. Heck, my bigint
RFC doesn’t even do that.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
oks fairly stable now and I’m unlikely to change it much further, so there’s
little worry about having to change the asm a second time. The main problem
with asm, I suppose, is testing it. I do have a 32-bit Ubuntu VM set up, but
I’d also need to set up Windows VMs, and possibly others (don’t we ha
aware zend_string vs. having a
Unicode-aware string aren’t quite the same. Certain string operations are only
possible for certain encodings, and by supporting any encoding we risk making
things confusing. I’d rather we convert everything to Unicode.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
401 - 500 of 1335 matches
Mail list logo
