uses the "as" keyword:
class Foo {}
This seems like a poor syntax choice to me. Usually the word 'as' is
used for aliases and such. If you hadn't told me its function here, I
would probably have been very confused. 'T1' isn't an alias of Bla,
right? It's some subclass.
Thanks.
e every keyboard layout perfectly, but we
should still take these things into account.
Thanks.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
dly accept anything because it's in hack,
but the fact that it's there means we also shouldn't diverge "just
because". If it makes sense to copy it, why not?
Couldn't have put that better myself.
Thanks.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing
.
Thanks.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
l
variable, to define a proper top-level function.
Hope this is helpful.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ntics in PHP and Hack, yet this
proposal matches Hack's implementation exactly, so far as I can tell.
Also, it would be nice if PHP and Hack don't diverge when implementing
the same features, unless there's a particularly good reason... it's not
very kind to people who use both languages.
So,
this in PHP. Are you going to write an RFC?
Thanks!
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
/bdcd9bbd29fac886192fbc410ccb96bd4cb93375
At some point, I might make a pull request to add this to PHP master, if
it provides a performance boost.
Thanks.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
to
be the consistent thing to me), but show an E_NOTICE warning you this is
happening?
I hope that's helpful.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
inspire someone. There is hope!
Hope my thoughts are somewhat helpful.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
it (make it call div_function_no_error or
something?)
Thanks.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Bob,
On 2 Jul 2015, at 01:26, Bob Weinand bobw...@hotmail.com wrote:
Am 29.06.2015 um 19:14 schrieb Andrea Faulds a...@ajf.me:
Hmm. Using Error might make some sense given it used to raise E_WARNING. I
think DivisionByZeroError sounds like a good idea.
Hey,
I just committed
and that’s what’s done for them.
I hope that makes sense.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
DivisionByZeroError or similar? (yes, I know, Error is
only very recent, but the question still needs to be asked).
Hmm. Using Error might make some sense given it used to raise E_WARNING. I
think DivisionByZeroError sounds like a good idea.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP
, PDO or SPL classes.
Thoughts ?
Sounds good to me! There’s already a precedent for having internal classes
special with respect to Closure binding, as you can’t bind a method of an
internal class to an object not of that class.
Thanks.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals
can arbitrarily re-scope closures, but that's how it is.
Also, if information leaks are a worry, we've had things like ob_start() and
var_dump(), and (array) for a while now.
A further thought: type hints for class properties would be helpful here.
Thanks.
--
Andrea Faulds
http://ajf.me/
in your summary.
Exceptions for negative shift, modulo/intdiv by zero, normal division by zero
is +/-INF. :)
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
the same
thing as % and / division and produces FALSE with a warning. If % is changed,
intdiv() should be too, because they are the same operation, just returning
different parts of the result. An exception being produced by both would seem
reasonable.
Thanks.
--
Andrea Faulds
http://ajf.me
, if a division by zero
happens, don't evaluate the expression at compile-time?
Thanks.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
the most sensible solution would be to make negative shifts produce an
exception, since they’re really an error, an unsupported operation. I made them
be a warning + return FALSE just because it matched division. But that’s not
ideal and I’d be fine if it was replaced.
Thanks.
--
Andrea Faulds
with
him just to be sure.
One thing of note is that I didn’t write a language specification patch. If
you’re to pick it up, I guess you’d have to do that at some point, sorry about
that.
Thanks.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
Hi,
On 15 Feb 2015, at 12:39, Xinchen Hui larue...@php.net wrote:
On Sun, Feb 15, 2015 at 10:46 AM, Andrea Faulds a...@ajf.me wrote:
Hi everyone,
I should’ve done this a long time ago, but I’m going to hold a vote on this
RFC. The implementation isn’t finished, but the remaining work
extension that may crash the
PHP interpreter and DoS your web host in order to do large number arithmetic.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
. Now that voting’s cancelled, that
could be fixed properly if someone revived the RFC.
I think the vote totals still make a statement. The vote may have ended 4 days
early, but it’s only 1 vote short of a 2/3 majority.
I’m not sure, really.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals
it to?
Thanks!
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hey François,
On 14 Feb 2015, at 04:57, François Laupretre franc...@php.net wrote:
That's a nice addition and a beginning to distinguish void from null, as I
imagine the function still returns null.
Now, what about making void a real zval type ? It would open a lot of
possibilities.
Hi,
On 14 Feb 2015, at 03:32, reeze re...@php.net wrote:
Do we really have to throw an catchable fatal error?
the other return types make sense, why so strict?
We throw E_RECOVERABLE_ERROR for all type errors, both for parameters and
return types. It's not anything new.
--
Andrea Faulds
Hi,
On 14 Feb 2015, at 05:03, Xinchen Hui larue...@php.net wrote:
Hey:
be honest, I think it's only part of the idea is implemented.
which make it useless.
in PHP, even if you don't return anything, NULL is returned implicitly.
even if a function is declared return nothing(void).
and the fact there are so many
people trying to make PHP that makes me sad.
It's not merely for the sake of it. It makes function signatures more
descriptive, and lets you catch bugs in your code.
We already use void in the manual: why not in PHP?
--
Andrea Faulds
http://ajf.me/
--
PHP
the same behaviour as your RFC but without the inconsistency
That seems like a strange solution. You’re requiring the function to always
return a useless value.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net
Voting starts today (2015-02-15) and ends in 10 days (2015-02-25).
If you have any queries, please ask.
Thanks!
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
), much like isset($a, $b, $c) is equivalent to (and
implemented as) isset($a) isset($b) isset($c).
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 13 Feb 2015, at 11:16, Andrea Faulds a...@ajf.me wrote:
Hey,
On 13 Feb 2015, at 07:28, Michael Wallner m...@php.net wrote:
On 12/02/15 19:55, Thomas Punt wrote:
I'd like to propose to make empty() a variadic, where if any
arguments passed in are considered empty, then false
.
Anyhow, we could catch such errors prior to call-time by extending the callable
typehint to take a parameter list, such that parameter type hints can be
checked (with the same rules as used by inheritance). This would solve your
problem.
Thanks.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals
\Math\{sin, cos, tan, degrees, radius};
Much better, no? I know which one I’d rather read and write.
It’d be a real shame if this doesn’t pass.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 13 Feb 2015, at 17:18, Lester Caine les...@lsces.co.uk wrote:
On 13/02/15 16:41, Andrea Faulds wrote:
But with Marcio’s proposal, we could instead write this:
use function SomeLibrary\Math\{sin, cos, tan, degrees, radius};
Well it used to be simply ...
require SomeLibrary
added to them.
* Contravariance is widely accepted as being sound for parameter types.
* We already have covariance for return type existence. So why not
contravariance for parameter type existence?
I hope we can have this added.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP
Hi everyone,
I’ve written a small RFC and patch to add a “void” return type:
https://wiki.php.net/rfc/void_return_type
Please have a read over it. I think this would be a simple, yet useful addition.
Thanks!
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development
Hi,
On 12 Feb 2015, at 07:05, Pavel Kouřil pajou...@gmail.com wrote:
On Thu, Feb 12, 2015 at 1:13 AM, Andrea Faulds a...@ajf.me wrote:
A number (or numeric, or num, or some other name) type hint is something I
plan to propose in a future, follow-up RFC.
wouldn't polymorphism (via
.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
, PHP_INT_MAX
$x, !isfinite($x), isnan($x)).
Also, even though PHP does allow most float-int conversions with weak typing,
it doesn’t mean they’re a good idea. Silently losing the fractional part is
probably not what you want.
Thanks.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP
return 1; // okay
}
function foo(number $x) {}
foo(1.0); // okay
foo(1); // okay
I don’t see why it “wouldn’t work”.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Exception(type .gettype($x). not supported);
}
}
Which is cleaner IMO.
We could also add some sort of pattern-matching syntax which could do the same
thing, but would have usefulness beyond merely dispatching to multiple methods.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP
would just mangle the error value (like
FALSE).
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
”);
}
This way, only code made “PHP 7-ready will have to replace its references to
String with, say, StringHelper. Drupal can work on both PHP 5 and PHP 7, but
codebases using it can migrate at their own pace.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
On 11 Feb 2015, at 21:30, Zeev Suraski z...@zend.com wrote:
-Original Message-
From: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
Sent: Wednesday, February 11, 2015 8:37 AM
To: Xinchen Hui; Andrea Faulds
Cc: PHP Internals
Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints
On 02/10
of numeric scalar type
There're others, but these ones are keys to make them fully usable.
A number (or numeric, or num, or some other name) type hint is something I plan
to propose in a future, follow-up RFC.
Thanks.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime
,
no?
I do not understand your logic.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
() statement last.
Well, yes, in a project with multiple people, you must conform to the project
style guide and such, that’s hardly unusual.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
of weak or strict consensus in the
community, no matter whether it’s nice for API design or not.
Thanks.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
. The issue of scalar type hints is highly controversial in
general for these reasons.
There is no consensus whatsoever. To suggest there is would be to grossly
exaggerate.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
be dealt with in future. The RFC
is more about the language change than the implementation.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
already has a voting
option on reserving the type names, and it is set to pass, so by the time your
RFC could go to a vote, it would have been rendered redundant.
Thanks.
--
Andrea Faulds
http://ajf.me/
, but introducing a competing RFC *while its
competitor is in voting* is both poor sportsmanship, and quite probably futile.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 8 Feb 2015, at 15:48, Andrea Faulds a...@ajf.me wrote:
If this RFC would somehow pass, yes. However, you’re introducing a competing
proposal at the “eleventh hour”, so to speak, which is terribly nice. Unless
there’s a radical shift in how people vote on the Scalar Type Hints RFC
/MBadR
That would be a BC break, and the kind of non-obvious evil one Derick doesn’t
like much.
Though I can’t talk: I already ‘broke’ bitwise shifts with the Integer
Semantics RFC.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit
Hi François,
On 8 Feb 2015, at 20:43, François Laupretre franc...@tekwire.net wrote:
De : Andrea Faulds [mailto:a...@ajf.me]
Instead, I’m wondering if the following might be better:
?php strict
Which would be used like so:
?php strict
function foobar(): int
considering a specific
change of syntax.)
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
.
Please stop repeating this, it is blatantly false and I’ve pointed this out
several times.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
convert binary strings into integers on array keys
* allow bitwise operators on binary strings without casting to integer
This would break existing code which was made “PHP 6-ready”.
Also, we already support bitwise operations on strings, I don’t know what
you’re on about there...
--
Andrea Faulds
eventually
succeed where everyone else failed thus far!
Thanks.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
and StackOverflow, was even less
positive than internals, considerably so.
So, I think that to say that there was “zero controversy” is certainly
stretching the truth. Really, I’m yet to see any scalar type hinting
discussions which haven’t had some controversy.
--
Andrea Faulds
http://ajf.me/
--
PHP
there was (and probably still is) almost consensus.
Again, there was not consensus. The RFC was controversial, especially outside
of internals, but even on internals around half the people who responded *were
not positive*.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing
Hi,
On 8 Feb 2015, at 23:22, Rowan Collins rowan.coll...@gmail.com wrote:
On 08/02/2015 19:44, Andrea Faulds wrote:
Hi,
I’m posting this in a new thread since people might (reasonably) be ignoring
further responses to the [VOTE] thread.
Incidentally, you still used reply to create
Hi Pavel,
On 7 Feb 2015, at 10:57, Pavel Kouřil pajou...@gmail.com wrote:
On Thu, Feb 5, 2015 at 9:14 PM, Andrea Faulds a...@ajf.me wrote:
Good evening,
At long last, I’m going to put the RFC to a vote. It’s been long enough - I
don’t think there needs to be, or will be, much further
Hi,
On 7 Feb 2015, at 20:47, Andrea Faulds a...@ajf.me wrote:
On 7 Feb 2015, at 10:57, Pavel Kouřil pajou...@gmail.com wrote:
I just realized it now (I brought it up in a different manner when
there was discussion about the RFC), but I didn't notice there was a
totally false statement
Hi,
On 7 Feb 2015, at 22:03, Pavel Kouřil pajou...@gmail.com wrote:
On Sat, Feb 7, 2015 at 9:57 PM, Andrea Faulds a...@ajf.me wrote:
Hi,
On 7 Feb 2015, at 20:47, Andrea Faulds a...@ajf.me wrote:
On 7 Feb 2015, at 10:57, Pavel Kouřil pajou...@gmail.com wrote:
I just realized it now
this ability of declare(); or at least
produce some sort of warning (E_DEPRECATED? E_WARNING? E_STRICT?). It’s highly
misleading and I don’t really understand why it’s allowed.
Then again, that would cause problems for ticks, possibly?
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP
Hi,
On 8 Feb 2015, at 02:51, Andrea Faulds a...@ajf.me wrote:
Yes, the RFC is somewhat inaccurate in that respect. It is per-file in one
sense (like encoding, but unlike ticks, it has no effect on the including or
included files). However, it technically affects the remainder of the file
Hi,
On 8 Feb 2015, at 03:52, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 02/07/2015 09:51 PM, Andrea Faulds wrote:
tan(1);
echo strstr(test, est, 1);
Banning int-float and float-int is both a pain point and sometimes a
life-saver. It’s annoying that tan(1) doesn’t work. On the other
that is 'the PHP way' and some of the
flexibility PHP currently provides is actually constrined in a much more
practical manor than the current proposals.
I hardly see the need for constraints in this case: we’ve had if() and throw
for ages now, and they do this specific job perfectly well.
--
Andrea Faulds
require subclassing checks.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
will vote “yes” for the competing RFC which is 80% of your
RFC. Why are we not given that option??
Because I cannot in good conscience push through something in the name of
“consensus” which does not even approach it.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime
are not the same thing.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
to
have to type on every file. But, I think it seems to work out better overall
than all the numerous other proposals I’ve seen so far, and that’s why I like
it.
I also need sleep.
Goodnight!
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
people’s) is better than
covering only one of two.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
to
be better for catching errors ahead-of-time, and I think with return types
it’ll get even better.
Thanks for your input.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
” was Zeev in that
context):
On 15 Jan 2015, at 14:51, Andrea Faulds a...@ajf.me wrote:
Let’s have a look. From a quick skim over the thread for v0.1:
* In favour of weak types (or the RFC anyway): Adam, Stas, yourself, Jordi,
Pierre,
* Against, in favour of strict types: Maxime, Nikita, Markus
sense.
If someone wants to make a separate RFC later for strict types or weak types or
whatever, nothing would stop them.
Thanks.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
of time, too. You
can’t do that with weak typing, because it depends on the value, not the type.
And you don’t know the value from reading the source code.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
returning multiple types, bitwise operators and array indexing. All of these
discriminate between types. To claim that types are merely an aspect of a zval
is ignorance in the extreme.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
, and it contains a voting widget:
https://wiki.php.net/rfc/scalar_type_hints
Thank you for your time.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
the Casing Rules Used by Titles. Of php\HTTP and
php\http, php\http is probably better since the case matches that of php\. It
could also be PHP\HTTP, I guess, but lowercase is somehow more appealing to me.
Thoughts?
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development
type hint?
I think the BC cost, while unfortunate, is unavoidable. Luckily, code can be
changed in such a way that it’ll keep working fine on PHP 5 and only break on
PHP 7, by using class_alias().
Thanks.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing
.
Thanks.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
variables. The above case would be fine as well since 1 can be int or float
(pretty much as Haskell is handling it)
Yeah, I only had int/float issues when I turned on strict mode in my app. And
that caught a bug, actually, so I was quite thankful for it.
--
Andrea Faulds
http://ajf.me
. They’re a tool for
catching errors early, and to enable better documentation. That’s all that they
do.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
of reverting the DateTime BC break, I'm wondering if it wouldn't be
better to fix the root cause by making the inheritance check less strict
and allow removing typehints?
Sounds sensible to me.
Of course, the reverse is true for return types, which should be either
covariant or invariant. :)
--
Andrea
been covered extensively.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
range of values, but still allows at
least what the interface requires it to, it is not an LSP violation. Scalars
are not special.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
for
two reasons. Firstly, you can’t assign to constants, and secondly, it’ll be
syntax-highlights differently.
I can understand your concerns, though. :)
Thanks for voicing them.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
Hi,
On 3 Feb 2015, at 14:43, Leigh lei...@gmail.com wrote:
On 3 February 2015 at 14:36, Andrea Faulds a...@ajf.me wrote:
I don’t know where you got that idea. The binary ops are consistent - they
aren’t constrained by register size like in previous PHP versions, but
they’re still
On 3 Feb 2015, at 14:59, Leigh lei...@gmail.com wrote:
On 3 February 2015 at 14:49, Andrea Faulds a...@ajf.me wrote:
It’s not “broken”, the behaviour is just different to account for it now
being an arbitrary-precision type.
That's pretty much the definition of a BC issue.
Sure, it’s
On 3 Feb 2015, at 14:15, Leigh lei...@gmail.com wrote:
On 3 February 2015 at 13:54, Andrea Faulds a...@ajf.me wrote:
Hi Leigh,
On 3 Feb 2015, at 13:51, Leigh lei...@gmail.com wrote:
No idea. Personally I'm opposed to the bigints implementation because
of the implicit type auto-promotion
is the number of existent PHP frameworks and libraries. Every single
application would have its own approach. It’d be chaotic, and not terribly
user-friendly.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 3 Feb 2015, at 14:49, Lester Caine les...@lsces.co.uk wrote:
On 03/02/15 14:03, Andrea Faulds wrote:
But I don’t consider 0.25MB extra to be such a problem in practice. The PHP
binary is already huge, and every system running PHP will have ample memory.
Yes one approach is 'computers
On 3 Feb 2015, at 15:12, Leigh lei...@gmail.com wrote:
On 3 February 2015 at 15:02, Andrea Faulds a...@ajf.me wrote:
Why would it be promoted?! The high bit is the 63rd bit. It fits within a
long.
I'm assuming your bigint implementation would want to respect signage.
When does
On 3 Feb 2015, at 16:22, Leigh lei...@gmail.com wrote:
On 3 February 2015 at 15:02, Andrea Faulds a...@ajf.me wrote:
Why would it be promoted?! The high bit is the 63rd bit. It fits within a
long.
because
On 3 February 2015 at 16:08, Andrea Faulds a...@ajf.me wrote:
$ sapi/cli
not a perfect solution, but I haven’t seen anything that seems to be much
better. The best bit about declare() is that it would make strict types
completely optional, so people who don’t like them wouldn’t have to use them,
even if they call code which does.
--
Andrea Faulds
http://ajf.me/
--
PHP
Hi Leigh,
On 3 Feb 2015, at 13:51, Leigh lei...@gmail.com wrote:
On 3 February 2015 at 13:25, Andrea Faulds a...@ajf.me wrote:
Hmm, how would this interact with bigints? Does it rely on fixed-width
integers, as it appears to? :/
No idea. Personally I'm opposed to the bigints
401 - 500 of 1301 matches
Mail list logo
