and $url pick up those named arguments.
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
and replies on it would also be
sent to the mailing list in the appropriate format, so that people
reading the mailing list could still see what was going on.
Thoughts?
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
!
So we should add that stuff to news.php.net, then? I suppose it would be
nice to be able to reply directly from there, too, then. Sending an
email or posting in a newsgroup can't be very hard from PHP, I'd imagine...
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development
comments: now the most useful, and (hopefully) least
absolutely terrible ideas security-wise are the top.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
moderation by
the community. Nobody is muted or banned, but bad ideas or troll posts
get downvoted to the bottom, whilst good ideas get upvoted to the top.
Hacker News, in particular, has some very good discussions.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development
with the
downside of people downvoting different opinions, it would still be
worth it, I think, because of how it could deal with trolls.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
to create a new community. Please read the backlog.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
assume PHP4?
I'm editing it right now. Not sure why you can't find it, here:
https://git.php.net/?p=web/news.git
or https://github.com/php/web-news
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
can use the development
server to debug it. Now that I've done that, I think I'll get started on
making news.php.net build up a database of post relations so it can do a
hierarchical view.
Andrea Faulds is it ok to contact you off list for this on monday?
Sure thing.
--
Andrea Faulds
http
On 11/09/2013 19:20, Rasmus Lerdorf wrote:
On 09/11/2013 10:39 AM, Andrea Faulds wrote:
You are free to set up a forum somewhere and discuss anything you want,
but internals as a mailing list is not going anywhere, sorry.
-Rasmus
Perhaps you didn't read my replies, or I didn't make myself
the mailing list directly, but could also
look at the web view with its hierarchical format and upvotes and
downvotes. It also means people could use the web interface exclusively
if they wished.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
feel free?
Hope for the fruitful cooperation,
I don't.
Best regards,
Robert Froslev,
http://www.webhosting-hotel.com/
Go away,
Andrea Faulds,
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
withdrawn them, would it be possible to pick up the RFC(s)
where he left off? Would I have to ask his permission for that? Is there
a process for this?
Thanks in advance.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
On 17/09/2013 00:14, Pierre Joye wrote:
Not really, and just take what you wish.
I have a wiki account and I can edit RFCs. Could I edit, say, the
Function Autoloading one to non-Withdrawn and add myself to the Authors,
then announce it here?
Thanks!
--
Andrea Faulds
http://ajf.me
you're after?
Hope this helped.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 17/09/2013 20:28, Yasuo Ohgaki wrote:
I'm questioning about getting the data inside PHP with new code in
master branch,
not in user script.
Oops, how silly of me. I must be tired if I thought that was PHP code.
Apologies.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime
was scared that it was just me, I suppose I can be glad I'm not the
only one.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
reasons behind it.
So I think it would be best to allow neither of those, for the sake of
consistency.
(OT: I've also just discovered that Python supports a, b, *c = someseq
for multiple assignment, perhaps we could see list($a, $b, ...$c) =
$someseq support?)
--
Andrea Faulds
http://ajf.me
be as easy since you'd have to chop up the ...$args in
the definition, but all may be sacrificed in the name of
backwards-compatibility. :P
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
$_REQUEST but for
the request body exclusively ($_BODY). We'd then have $_GET for query
parameters and $_BODY for request body (POST, PUT, PATCH, etc.)
parameters. While at it, why not add a better version of $_GET which
doesn't replace certain characters with undescores?
--
Andrea Faulds
http
becomes:
ext/standard/php_array.h:119:
#define ARRAY_FILTER_USE_KEY 1
#define ARRAY_FILTER_USE_VALUE 2
#define ARRAY_FILTER_USE_BOTH 3
Such that we have the best of both worlds, either
`ARRAY_FILTER_USE_BOTH` or `ARRAY_FILTER_USE_KEY |
ARRAY_FILTER_USE_VALUE` :D
--
Andrea Faulds
http
On 27/09/2013 08:17, Gordon Oheim wrote:
I think this is a great proposal. Anything that reduces code verbosity,
increases programmer productivity, improves readability and doesn't
bloat PHP gets my support.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development
handlers from extensions, ext/json may be an
example, like it is hacked into pecl_http-v2.
+1 Handling JSON would be pretty neat. Maybe we could even support it by default
(after all, there is the json ext), so long as getting the unparsed request body
isn't impeded by that.
--
Andrea Faulds
http
Le 2 octobre 2013 à 10:58, Michael Wallner m...@php.net a écrit :
On 2 October 2013 11:56, Andrea Faulds a...@ajf.me wrote:
Backwards compatibility matters, so we should keep $_GET and $_POST but add
these as better aliases for them.
That's why I said phase out... or is it a german
in PHP-5.0 and removed
in PHP-5.4.
Well, perhaps $_QUERY and $_FORM can be added in 5.6, deprecated in 6.0 and
removed in 6.4, then? Who knows!
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
), though
ExpectationException might be confusing. I think we should name it
AssertionException.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
-1 to expect is a problem. expect is not a problem.
Le 21 octobre 2013 à 10:42, Joe Watkins krak...@php.net a écrit :
On 10/21/2013 09:57 AM, Tjerk Meesters wrote:
On Mon, Oct 21, 2013 at 4:16 PM, Michael Wallner m...@php.net wrote:
On 21 October 2013 10:13, Patrick Schaaf b...@bof.de
a strong hash with it (other
factors are at play), but it does say that you can't without it.
Perhaps secure might be better than strong.
Just my 2 pence.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
to
fix it when I have more time.
The patch is here: https://bugs.php.net/bug.php?id=6768
The RFC has been added to the list in Under Discussion.
Any thoughts, suggestions, etc. appreciated.
Regards,
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
could stop being fatal and start being exceptions, which
is great news.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
/plain, .html as text/html,
etc.), and guess the rest? Especially for ones which it would not
correctly guess.
Thanks.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
://github.com/php/php-src/commits/phpng/Zend/zend_types.h
[12:04am]ajf: Aha
[12:05am]ajf: Tyrael: and the most recent change, from laruence, is
there:http://lxr.php.net/history/phpng/main/php_variables.c
It would appear this issue has been resolved.
--
Andrea Faulds
http://ajf.me/
--
PHP
gone on for so long. PHP has idiosyncracies, but frankly, the is_null
function is hardly the worst of them and I see nothing useful resulting from
this discussion.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net
it if
everyone read the whole thing:
https://wiki.php.net/rfc/php6
The plan for voting, if I think we should go ahead with it, is the same as a
normal RFC: at least 2 weeks after proposed to internals, voting for at least 1
week.
Thanks!
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP
isn’t entirely ideal, but it’s not really important. I don’t
think it’s possible to change it, and this is at least memorable. Really, RFC
URLs are pretty meaningless. We’ve had URLs before with spelling errors in them.
Thanks.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime
.
Also, I disagree that holding a vote to settle the name matter once and for all
is a waste of energy. It should, hopefully, mean less energy wasted than
otherwise in future.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
with that is that I feel such a
narrow majority would be too contentious and not end the discussion for good.
Sadly, it is not realistic to hold a vote on the majority with which to vote. ;)
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe
On 6 Jul 2014, at 02:04, Christoph Becker cmbecke...@gmx.de wrote:
Andrea Faulds wrote:
I can see Zeev’s point that 7 is the main other option (though I also
think 6.1, or codenames, are possible though unlikely other options).
However, I don’t want to call a 50%+1 6/7 vote because it just
On 5 Jul 2014, at 22:23, Andrea Faulds a...@ajf.me wrote:
This RFC attempts to settle the matter once and for all with a straight
yes/no vote as to whether the name should be PHP 6. Should it pass, the
matter is settled and we actually have a proper name for this fabled “PHP
NEXT”. Should
was abandoned must be about a new PHP 6, and
anything from before it must be about the old PHP 6. If this RFC were to pass
with people voting for 6, then it would be pretty clear that anything coming
after it was about the new PHP 6.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP
and tested naming scheme, too.
I think that’d be for the best.
Side note: another thought comes to me now that just skipping 6 and going to 7
makes little sense in a way, as 7 isn’t the successor to 6, it is the second
successor to 5, the first (the old PHP 6) having been abandoned.
--
Andrea Faulds
On 6 Jul 2014, at 17:46, Lester Caine les...@lsces.co.uk wrote:
On 06/07/14 16:08, Andrea Faulds wrote:
I think it’s generally clear what’s for the new PHP 6 and what’s for the
old; anything from after the old PHP 6 was abandoned must be about a new PHP
6, and anything from before it must
Rationale with me (I
don’t want it to unintentionally be too 7-sided). If you can catch me on IRC,
that would be optimal.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
that there are only two votes, and used the
phrase “simple majority”.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Zeev. Heck, it’s a wiki, anyone with karma could edit if they liked (but please
ask first). All I’m waiting for is said contributions. :)
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 3 Jul 2014, at 18:29, Andrea Faulds a...@ajf.me wrote:
Either way, I think there should be some sort of warning (probably an E_NOTICE
or E_WARNING?) when this cast happens implicitly and the number is truncated,
such as in function calls. I’m tempted to remove this from Open Questions
year that PHP NEXT could happen,
though 2016 is probably more realistic.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
feel they have to
add it to phpng, because if phpng is to be PHP 6, then it would need to be
based off that branch.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
to start an RFC-based discussion for moving phpng to master
so that the uncertainties around it are removed.
phpng has mostly been just performance so far, right? Could we use this
opportunity, where it is not yet master, to make some deeper improvements?
--
Andrea Faulds
http://ajf.me/
--
PHP
On 7 Jul 2014, at 14:13, Zeev Suraski z...@zend.com wrote:
On 7 ביול 2014, at 08:59, Andrea Faulds a...@ajf.me wrote:
On 7 Jul 2014, at 13:57, Zeev Suraski z...@zend.com wrote:
I don't think it's a problem, because I don't think we're two years
away from releasing a phpng-based version
it concurrently with another test with the same
no-concurrent directive. So, if you had, say, a non-concurrent filesystem test,
and another one, and some unrelated tests, you’d have to run those two FS tests
sequentially, but you could still run unrelated tests at the same time.
--
Andrea Faulds
http
unless we switch to using an AST-based parser someday.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
of Symfony and ZF is not representative.
It is a tiny BC break and it’s for PHP NEXT (i.e 6 or 7), not 5.6. Why not?
It’s a tiny change which will bother some people but make everyone else’s life
easier.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
6. Nikic’s PhpParser would be useful for this, and he’s already made a tool to
help spot things this RFC would break.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
done and a vote will only be biased to begin with,
based only on given performance results. It can't end well.
Myself, I will be voting for phpng not for performance, but because I find the
internal API to be saner.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development
.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
of the
votes on syntax have been held either.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
-src/pull/717
I’m hoping I can get this into PHP 5.7. I think scalar type hinting would be a
valuable addition to PHP’s existing type hinting system.
Thanks!
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net
, and
that there is a system of typing, but it doesn’t say anything about its
strictness.
Regardless, this RFC will stick with the current terminology, but changing the
terminology would be quite simple, you could just update the manual and
possibly change some of the internal names.
--
Andrea Faulds
http
as
internal_function($_GET[‘id’]).
Also, it’s not really “what Andrea proposes”, it’s Anthony’s proposal, even if
he is sadly absent from the list these days. I’m just trying to fix up the
patch, iron out remaining wrinkles, and get this into PHP.
--
Andrea Faulds
http://ajf.me/
--
PHP
:
function foo($bar) {
if (!is_int($bar)) {
throw new Exception('Invalid parameter type');
}
}
If you really want to continue doing that, nothing would stop you.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
type here.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
); // E_RECOVERABLE_ERROR
Float hints:
function foo(float $a) {
var_dump($a);
}
foo(1); // float(1)
foo(1); // float(1)
foo(1.0); // float(1)
foo(1a); // E_RECOVERABLE_ERROR
foo(a); // E_RECOVERABLE_ERROR
foo(1.5); // float(1.5)
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development
their opinion
in before changing it in each direction :)
Zeev
Yes, I might have acted a little too quickly. However, I’m not sure “12a” is
such a common case. With the strict behaviour, foobar(“ 12”) and foobar(“12”)
still work, however foobar(“12 “) unfortunately would not.
--
Andrea Faulds
http
to the other type hints, which are strict, but is
also further away from zpp. I’m a big conflicted.
For now, I’ll leave it as E_RECOVERABLE_ERROR. While user input might be
problematic, it can just be filtered.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing
be really difficult
for a developer to guess what will be the PHP behaviour with this new syntax.
Well, they do. The results of implicit scalar type hint casts are, so far as I
know, the same as explicit casts, but some cases lead to errors which don’t in
an explicit casts.
--
Andrea Faulds
http
to hint for them, then?
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
here in 2012:
http://nikic.github.io/2012/03/06/Scalar-type-hinting-is-harder-than-you-think.html
However, I don’t propose “strict weak” typing, I propose this RFC.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net
On 13 Jul 2014, at 16:28, Rouven Weßling m...@rouvenwessling.de wrote:
On 13 Jul 2014, at 17:05, Andrea Faulds a...@ajf.me wrote:
On 13 Jul 2014, at 16:00, Rouven Weßling m...@rouvenwessling.de wrote:
One thing however seems like a rather bad idea, and that is exposing the
type
because we don’t
need it; if Bar extends Foo and a function takes a Foo, it can also take a Bar.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
implementation.
I’m thinking more about dealing with JSON and such which give you an object.
Perhaps you might have a FooBar-fromObject() method that can be passed another
FooBar to clone it, or an object decoded from JSON. Though in that particular
case there’s no real need for a type hint.
--
Andrea
.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
try to think about this, I
usually end up going in circles. Anthony doesn’t seem to be decided either.
Hence I’m putting this up for discussion.
What are your thoughts?
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
On 14 Jul 2014, at 14:28, Andrea Faulds a...@ajf.me wrote:
On 14 Jul 2014, at 14:12, Alexey Zakhlestin indey...@gmail.com wrote:
I don’t think that scalar casts” should do any additional error-catching.
they target a very different usecase.
It shouldn’t guarantee correctness
supporting both syntaxes has also been proposed in the past. That
isn’t this proposal and this proposal is not going to become that one.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
that
validate for the int type hint could be accepted. Is that a good idea? Though
it feels a bit loose, I think it covers all the important common use cases.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net
the existing cast logic, as explicit casts
*never fail*, so but existing casts work this way is not relevant.
Right. I’d like the rules to be simple enough. I think the string, int and
float ones make perfect sense and can be easily explained, it’s bool I’m
uncertain about.
--
Andrea Faulds
don’t like the idea of completely strict type hints here,
but I also don’t think that completely loose type hints that cast and do zero
validation are for the best either. This RFC tries to strike a compromise.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing
-scalar type hints except more lenient as it allows
equivalent values of other types.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
, if you run this:
set_error_handler(function () { return true; });
function foo(int $a) { var_dump($a); }
foo(“13abc”);
You would get this:
int(0)
However, that could easily be fixed so the error case uses the normal casting
behaviour.
--
Andrea Faulds
http://ajf.me/
--
PHP
On 14 Jul 2014, at 15:17, Andrea Faulds a...@ajf.me wrote:
On 14 Jul 2014, at 15:03, Rowan Collins rowan.coll...@gmail.com wrote:
Looking at the current table in the RFC, I'm not clear why NULL should pass
as any value, but not array. Could it not behave the same as the existing
type
) or (float) first
is probably a good idea.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
)$a;
}
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
that idea. If someone writes a function with type hints,
people shouldn’t be able to make those type hints go away or become more or
less strict. They should be consistent across environments and contexts.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
be
in normal maths, i.e. the fractional value 0.666…. Actually, this makes a good
case for return type hinting, as you could ensure you’d get an integer result
here. (But that is another matter.)
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
= Not Invented Here
We are using hack’s syntax (int, float, bool, string, no integer/double/boolean
aliases). We are not using Hack’s semantics for reasons that have been
discussed endlessly before in this thread and others, reasons which are not NIH.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals
Python 3 does: if two
integers cannot divide cleanly, then a float division is done instead. This may
not be what C, C++, C#, Java, or some other strictly-typed languages do, but it
is what PHP does, and has done for a long time. It’s also what makes the most
sense, IMO.
--
Andrea Faulds
http
for
anything
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 14 Jul 2014, at 18:38, Rowan Collins rowan.coll...@gmail.com wrote:
Andrea Faulds wrote (on 14/07/2014):
On 14 Jul 2014, at 18:24, Rowan Collins rowan.coll...@gmail.com wrote:
If the current type hints were only for objects, I would be OK with that,
but I really don't get why an array
” arrays and objects much, do we? You can
cast to them, sure, because PHP as a rule allows you to cast anything to
anything explicitly (bar resources), but I can’t, for example, do a loose
comparison between an array and a string.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime
On 14 Jul 2014, at 13:58, Andrea Faulds a...@ajf.me wrote:
One of the issues with the RFC as it stands is how to handle bool casting.
While int, float and string only allow lossless casting (with the exception
of objects, but we can’t really do anything about that), bool’s behaviour
).
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
addition.
Thanks!
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
up to 53 bits but not
beyond?
No idea. This RFC isn’t proposing that.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RFC can’t come soon
enough given Y2K38).
However, intdiv() is perhaps not the best way to implement it or the best
syntax.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
use \ for namespaces, and Python 3’s // obviously can’t be used, so I might
suggest Pascal’s div operator:
$minutes = ($s div 60) % 60;
Failing that, div() as a built-in function much like pow() is:
$minutes = div($s, 60) % 60;
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime
the
range problem where a 64bit value may be required but the installation
on4y supports 32bit integers. Currently the value simply works with the
string version …
Yeah, hence why I’m also proposing the bigint RFC, which intdiv() would work
nicely with.
--
Andrea Faulds
http://ajf.me/
--
PHP
when a basic PHP installation is used.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
casts which have
stricter rules than an explicit cast, and also somewhat stricter than
zend_parse_parameters, meaning that people can safely do $_GET[‘thing’] and
it’ll work, but if a nonsensical value is passed in, the program will error as
it should.
--
Andrea Faulds
http://ajf.me/
--
PHP
1 - 100 of 1301 matches
Mail list logo
