Hi all,
On Tue, May 26, 2015 at 3:02 AM, Rowan Collins rowan.coll...@gmail.com
wrote:
On 24/05/2015 22:32, Yasuo Ohgaki wrote:
Does this include internal function type errors?
e.g.
$ php -r 'var_dump(mt_srand(999));'
PHP Warning: mt_srand() expects
/functions first,
then
introduce as \ few years later. i.e. PHP classes/functions exist in both
\ and \php
namespace during migration period or we may user INI switch for migration.
PS: I like a lower case php much more than upper case PHP ;)
I'm neutral on this :)
Regards,
--
Yasuo Ohgaki
yohg
(...); // Uses builtin DateTime from root namespace
+1 for as \
It achieves both clean namespace and compatibility at the same time.
It opens door for easier API version up also. Automatic fallback disturbs
this.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
,
--
Yasuo Ohgaki
yohg...@ohgaki.net
On Thu, Jun 4, 2015 at 1:35 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
On Thu, Jun 4, 2015 at 7:33 AM, Brian Moon br...@moonspot.net wrote:
This is a better representation of what you are trying to show. It
removes all the magic call back stuff that could be adding to the slowness
you
as \u by default, disable
\u
encoding as an option.
BTW, any progress on disabling automatic float conversion against float like
values? This is mandatory, IMHO.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
.
Getting rid of
_ might be good enough for most methods.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
method names.
Keeping old names as alias is fine for me, but main names should be
standard names.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
));'
PHP Warning: mt_srand() expects parameter 1 to be integer, string given in
Command line code on line 1
NULL
If not, please make these exceptions rather than E_WARNING.
We need consistency here.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
$callback [, bool $single_line_try_block =
FALSE])
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
be implemented as independent functionality not needing
modification of the engine or opcache.
Right. Users could implement whitelist by themselves.
However, isn't it nice to have this feature? It does not have any
performance penalty.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
include('/path/to/upload/attack_image_file.png');
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Hi Francois,
On Sat, May 16, 2015 at 10:04 PM, François Laupretre franc...@php.net
wrote:
De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo
Ohgaki
As some of you know that I'm trying to to eliminate script inclusion
attack.
I come up with another idea which may
templates for
production.
- Users/libraries should create intelligent white list for dynamically
created scripts.
(The file to be compiled does not have to exist at startup)
I prefer 3rd option.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
researched this in previous thread.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
don't have to preload script one by one using
opcache_compile_file().
These options may be PHP/Zend or opcache options.
I hope everyone like the idea.
Any objections and/or comments?
Regards,
P.S. It's for PHP 7.1, of course.
--
Yasuo Ohgaki
yohg...@ohgaki.net
to develop, less complex code, etc.
Good point. Preload module may be a good option.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Hi Stas,
Thank you for pcntl_exec() null byte fix.
I forgot this. I've closed the bug.
I'll start dealing with assigned bugs soon...
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
On Fri, May 15, 2015 at 4:20 PM, Stanislav Malyshev smalys...@gmail.com
wrote:
Hello!
The PHP development team
will not have wrong
assumption.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
integrated. PHP is made for web and interaction. JSON supports
numeric
that has undefined(unlimited) precisions, databases support huge numbers.
Advocating
users to use string type hint for these seems impossible. We'll see the
result soon.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
way to
store too large ID
somewhere (e.g. as JSON/XML text that queries database), then system may
use the
value against type hinted functions/methods.
Without basic type hints, these concerns weren't existed.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
E_RECOVERBLE_ERROR
does not make much sense.
Regards,
P.S.
With strict_types=1, mt_rand() gives
Fatal error: mt_rand() expects parameter 2 to be integer, string given in
/home/yohgaki/t.php on line 3
--
Yasuo Ohgaki
yohg...@ohgaki.net
, string given in
Command line code on line 1
NULL
However, returning NULL for invalid range may result in serious issues.
It's not documented in UPGRADING.
Could anyone responsible take care of it?
I suppose mt_srand() behavior has changed also.
There may be others.
Regards,
--
Yasuo Ohgaki
yohg
forgot about it even if I supported the RFC because of
these functions.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
with a catch
(TypeException $e) you'll be able to handle argument type errors - this
includes both errors for user typehints and for internal function types.
Thanks again,
It even worked on 3v4l
http://3v4l.org/sp1C4
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
/E_RECOVERABLE_ERROR according to
the RFC.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Hi Rowan,
On Thu, May 14, 2015 at 6:19 PM, Rowan Collins rowan.coll...@gmail.com
wrote:
Yasuo Ohgaki wrote on 14/05/2015 06:19:
I guess DbC will not prevent users from abusing type hints, though.
They'll only abuse them in exactly the same way they currently abuse
existing checks
add/extend is_digits()/is_numeric() for this. It would be handy
for DbC also.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Hi all,
On Wed, Apr 29, 2015 at 8:50 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
External data can have any form of numbers.
Current PHP can handle them as string. However PHP7's type hint cannot
handle numeric data well because it only has int and float hints.
http://3v4l.org/6J0bZ
-hint-for-external-data
Any comments?
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
for the value may
be used automatically/semi-automatically. It's good for both security and
performance.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
creates issue. Weakening
a bit does not harm any, narrowing window to attack. If user needs native
int/float strictly, they should/can use strict mode also.
Do you see issues with relaxing?
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Hi Walter,
On Thu, Apr 30, 2015 at 3:12 PM, Walter Parker walt...@gmail.com wrote:
And that is relevant how? How many Android phone run PHP applications?
Search web for IoT devices that can run PHP.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
...
Which is easier to advocate?
- Use string type hints for record ID/etc and validate value by yourself.
- Use numeric type hints for record ID/etc.
or even
- Use _weak_ mode int type hints (If it's relaxed)
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
by too large value because PHP stops execution
by fatal error. i.e. DoS became easy. I will never write such code, but I
don't
want to check and fix library that I would like to use. I don't think I can
manage
programmers to do that even if they are under my control.
Regards,
--
Yasuo Ohgaki
yohg
Hi Francois,
On Wed, Apr 29, 2015 at 7:03 PM, François Laupretre franc...@php.net
wrote:
De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo
Ohgaki
External data can have any form of numbers.
Current PHP can handle them as string. However PHP7's type hint cannot
breaking a lot of code under 32 bit machines with PHP 7.0
is not good thing to do.
In addition, current code does not even allow GMP object as int.
http://3v4l.org/GiklL
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Hi Francois,
On Thu, Apr 30, 2015 at 6:23 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Allowing any forms of int/float as string(and GMP) for weak mode int/float
type hint
would be alternative resolution for this issue. I think it's better than
numeric type
hint.
It seems current weak
Hi Christoph,
On Thu, Apr 30, 2015 at 7:10 AM, Christoph Becker cmbecke...@gmx.de wrote:
Yasuo Ohgaki wrote:
On Thu, Apr 30, 2015 at 6:27 AM, Christoph Becker cmbecke...@gmx.de
wrote:
A solution for this issue has been proposed by the Big Integer Support
RFC which has been withdrawn
/prevention
at all.
Having numeric type hint or StrictSTH RFC concept adoption are
possible resolutions. If there is better resolution, I appreciate it.
BTW, GMP integer is already integrated into PHP why not treat GMP as int?
It's type hint, isn't it?
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
efficient
than calling pseudo type checker functions (for now). Pseudo type checker
is useful and requires less code. I'm neutral to have it or not.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
accept GMP as PHP int in weak mode as it is, not converting C int.
Strictly speaking GMP has its type, but it can be used as string integer
now.
i.e. $gmp_int_a + $gmp_int_b works just like $str_int_a + $str_int_b.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Hi Rowan,
On Thu, Apr 30, 2015 at 11:00 AM, Rowan Collins rowan.coll...@gmail.com
wrote:
On 30/04/2015 02:24, Yasuo Ohgaki wrote:
Type hints have never been hints. The wording is a misnomer. Try to
pass an int to a parameter declared as array, for instance.
I understand how it worked
here.
We may have integrated GMP float in near future also. Accepting compatible
value/type is mandatory if it's a type hint for weak mode. I don't think
we
decided to have type declaration(type enforcement), do we?
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Hi Rowan,
On Thu, Apr 30, 2015 at 11:17 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
A fatal error wouldn't constitute a DoS vulnerability, would it?
Attacker may inject huge ID value and/or they may simply access
web sites to reach 2 billion limit, for example.
That's not a DoS vector
restriction is relaxed. Otherwise, having
numeric type hint
is mandatory to avoid type massive hint misuse. Writing big warning Do not
use
'int' type hint for database record IDs/etc, but use 'string' type hint and
validate by
yourself wouldn't help much.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Ryan,
On Thu, Apr 30, 2015 at 1:29 PM, Ryan Pallas derokor...@gmail.com wrote:
On Wed, Apr 29, 2015 at 8:37 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Rowan,
On Thu, Apr 30, 2015 at 11:17 AM, Yasuo Ohgaki yohg...@ohgaki.net
wrote:
A fatal error wouldn't constitute a DoS
issue.
Average PHP users will use int type hint for record IDs. This results in
fatal
error (or exception). These code does not have to be my/your code, but
other libraries written by someone else.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Dan,
On Thu, Apr 30, 2015 at 12:02 PM, Dan Ackroyd dan...@basereality.com
wrote:
On 30 April 2015 at 02:17, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Current PHP: Search query failure.
New PHP type hint: Fatal error because foreign key is out of PHP int
range.
There may be some confusion
://3v4l.org/6J0bZ (See how it works with large string integer value)
Any comments?
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
of
extra functions. I think dropping these only makes sense if we drop the
ability to have mbstring-specific or iconv-specific encoding settings
altogether.
I agree. This will work, too.
I don't mind keeping them at all.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
setting. My work is stopped by this.
Proper resolution for this would be introducing functions that set
input/output/internal
encoding for iconv.
If nobody objects, I'll add these and finish my patch.
Any comments?
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
://www.php.net/ChangeLog-5.php#5.4.40
https://bugs.php.net/bug.php?id=69353
There is similar bug.
I guess there wasn't enough time for this.
https://bugs.php.net/bug.php?id=69418
I made this bug a security bug.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
can keep
sorted state if you use class.
Natural place would be SplArray, but the implementation is overly
complex...
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Hi Jakub,
On Sat, Apr 11, 2015 at 1:37 AM, Jakub Zelenka bu...@php.net wrote:
On Fri, Apr 10, 2015 at 1:29 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Could you add json_encode type hint also?
Large int/float must be treated as string or GMP object (we don't have
GMP float yet, though
the return
value of false, should be good enough.
Same here, too.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Hi Jakub,
On Mon, Mar 30, 2015 at 5:45 PM, Jakub Zelenka bu...@php.net wrote:
On Mon, Mar 30, 2015 at 1:07 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
int should be fixed also.
http://3v4l.org/95dHM
We have already fix for this: JSON_BIGINT_AS_STRING (
http://3v4l.org/vYXUk )
Excellent
Hi Pierre,
On Mon, Mar 30, 2015 at 11:42 AM, Pierre Joye pierre@gmail.com wrote:
On Mon, Mar 30, 2015 at 9:14 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Pierre,
On Mon, Mar 30, 2015 at 10:54 AM, Pierre Joye pierre@gmail.com
wrote:
Same effects but totally unrelated topics
Hi all,
On Mon, Mar 30, 2015 at 9:07 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Jakub,
On Mon, Mar 30, 2015 at 4:33 AM, Jakub Zelenka bu...@php.net wrote:
I would like to add a new option to JSON for dealing with large floats.
The
use case is mainly for decoder but can be used
Hi Benoit,
On Sun, Mar 29, 2015 at 2:49 AM, Benoit Schildknecht bensor...@neuf.fr
wrote:
Why hasn't it closed ? It's way past the 25th.
Vote was closed before the end date. IIRC.
It's withdrawn status, I suppose.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
JSON_INT_AS_STRING.
PHP7 should have string scalars by default. IMHO.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
/negative value.
Casting external values to int/float is wrong and evil simply. Current type
hint
encourages/requires casts even if users are not realizing the consequence
fully.
We do make mistake like this bug. We cannot assume PHP user will not.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
fully.
I don't think these warnings prevent misuse, but better documentation may
help.
If there is anything should be added, please mention them in the document.
Just my .02 for people who are going to write document for basic type hint.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
rid of them, PHP 7 is the time.
+1
--
Yasuo Ohgaki
yohg...@ohgaki.net
reasons in
Command line code on line 1
Returning true for is_callable/class_exists even when it isn't usable does
not make much sense. How about fix them all?
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
their thoughts are.
I'm +1 for this change.
Having E_DEPRECATE before removing would be nice. Some users may rely on
this.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
for this change.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
is going to use namespace
ASAP. It gives us a lot freedom for introducing new API while keeping
compatibility.
I fully agree that consistency is very important. Let's be consistent as
much as possible.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
fix.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
session management is not predictable and precise at all.
If there is better idea other than the RFC, I appreciate it.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Hi all,
On Sat, Mar 21, 2015 at 6:43 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
On Fri, Mar 20, 2015 at 7:12 PM, Mateusz Kocielski s...@digitalsun.pl
wrote:
Doh, it's happening again, it was discussed before. Anyway, your solution
seems to not fix the real problem behind the bug entry. I
Hi all,
On Sat, Mar 21, 2015 at 6:43 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Please note that if destroy fails, then new session is not generated,
possible (but ugly) solution is to call session_regenerate_id again.
It just does not work.
How do you keep session for lost session
Hi Rowan,
On Fri, Mar 20, 2015 at 7:12 AM, Rowan Collins rowan.coll...@gmail.com
wrote:
On 19/03/2015 20:50, Yasuo Ohgaki wrote:
Hi Sebastian,
On Thu, Mar 19, 2015 at 9:48 PM, Sebastian B.-Hagensen
sbj.ml.r...@gmail.com mailto:sbj.ml.r...@gmail.com wrote:
2015-03-19 12:51 GMT+01:00
the replacement before it's worth even thinking about
deprecating something.
Deprecation is future scope that may be years later if it may.
I fully agree. I would like to fix this bug now. Current behavior is very
annoying...
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Hi all,
On Sun, Mar 1, 2015 at 1:53 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
There are too many things that I would like to improve ;)
https://bugs.php.net/bug.php?id=69127
This bug is known fatal bug for session module. I proposed lazy_destroy
to fix
this before, but it declined.
I
on my end, that was definitely
the case.
Yes and I fully agree.
Anyway, unlike your proposal, I have to advocate users not to use type hint
for database INT8, JSON numeric, etc. It will be tough job...
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Hi all,
On Thu, Mar 19, 2015 at 6:37 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
On Wed, Mar 18, 2015 at 6:43 PM, Zeev Suraski z...@zend.com wrote:
FWIW, as someone who did play with the patch (both patches, of course),
I'm not sure why people are claiming you don't understand the RFC
. IMHO.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Hi Sebastian,
On Thu, Mar 19, 2015 at 9:48 PM, Sebastian B.-Hagensen
sbj.ml.r...@gmail.com wrote:
2015-03-19 12:51 GMT+01:00 Yasuo Ohgaki yohg...@ohgaki.net:
Distinguishing array and callable is problematic.
Array callable is better to be deprecated in the long run. IMHO.
Then how would
Hi all,
On Sun, Mar 1, 2015 at 1:53 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
https://bugs.php.net/bug.php?id=69127
This bug is known fatal bug for session module. I proposed lazy_destroy
to fix
this before, but it declined.
I think the name was wrong. With the proposal, session module
?
Very easy, explained a thousand times over. Bringing up the same false
arguments up again and again does really not help the discussion.
I didn't have my time to spent for the patch. So I don't verify this
by myself, but it seems common sense for this RFC.
Regards,
--
Yasuo Ohgaki
yohg
.
BTW, I suggest to remove the word strict from strict_types at least as
it is
not strict at all if caller(parent script) does not specify
strict_types=1.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
/validated as certain types with or without this
RFC, strict_types
should raise error for mismatched types. However, current proposal does not
do this
depending on how strict_types is used...
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
the first.
The name implies what it does.
The reason you think this is odd is because the behavior is odd.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Hi Pierre,
On Mon, Mar 16, 2015 at 5:17 PM, Pierre Joye pierre@gmail.com wrote:
On Mar 16, 2015 6:46 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Dennis,
On Mon, Mar 16, 2015 at 3:33 PM, Dennis Birkholz den...@birkholz.biz
wrote:
Am 16.03.2015 um 07:22 schrieb Yasuo Ohgaki
happen.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
On Mon, Mar 16, 2015 at 8:44 PM, Nikita Nefedov inefe...@gmail.com wrote:
On Mon, 16 Mar 2015 14:33:00 +0300, Yasuo Ohgaki yohg...@ohgaki.net
wrote:
Hi Derick,
On Mon, Mar 16, 2015 at 8:18 PM, Derick Rethans der...@php.net wrote:
To be frank, I don't think I don't like
Hi Matthew and all,
On Tue, Mar 17, 2015 at 5:34 AM, Matthew Leverton lever...@gmail.com
wrote:
On Mon, Mar 16, 2015 at 2:53 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi all,
I think this is important, but not many people realize the importance.
Therefore I created this as a new thread
to have native type for better performance.
https://www.sqlite.org/datatype3.html
PHP may have the same idea for better performance and code.
It works well with coercive type or strict type (Not currently proposed
one, though)
Comments are appreciated!
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
.
With this RFC, caller overrides security related setting. This means
scripts
that are prepared for type safety is ignored and it leads security breach.
It's just like turning on/off register_globals and allow_url_include by
caller.
It cannot be right... IMHO.
Regards,
--
Yasuo Ohgaki
yohg
Hi Dennis,
On Mon, Mar 16, 2015 at 3:33 PM, Dennis Birkholz den...@birkholz.biz
wrote:
Am 16.03.2015 um 07:22 schrieb Yasuo Ohgaki:
Caller _must_ satisfy callee requirements. This is simple principle to
write a secure code.
With this RFC, caller overrides security related setting
here
}
?
The declare here does just nothing.
?php
require lib.php;
foo(123); // will work
?
?php
declare(raise_type_error = 1);
require lib.php;
foo(123); // will give an error
?
Is everyone feel OK with this??
Regards,
--
Yasuo Ohgaki
yohg
strict types for basic types, what we
really need is type affinity for inputs. e.g. $_GET/$_POST/$_COOKIE.
https://www.sqlite.org/datatype3.html
--
Yasuo Ohgaki
yohg...@ohgaki.net
Hi all,
On Mon, Mar 16, 2015 at 11:16 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
It's natural that we have different point of views, but we can easily
understand/guess
the consequence of the RFC. Weak mode is simply too weak to be useful.
Strict mode will hide type bugs by errorless
Hi Dennies,
On Mon, Mar 16, 2015 at 11:36 AM, Dennis Birkholz den...@birkholz.biz
wrote:
Am 16.03.2015 um 03:16 schrieb Yasuo Ohgaki:
This code is an example that I posted in other thread.
e.g.
?php
function check_num_range(int $num) { if ($num 0 || $num 100)
trigger_error
bugs are not good thing to do.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
while there is the
proposal that finds it.
What I'm trying to say is Why don't we collaborate?. Let users fix bugs
at first, then
introduce more strict type checks if it's needed. Coercive type and strict
type can co-exist
together well, but weak type and strict type cannot.
Regards,
--
Yasuo
agree partly. It does not provide any additional feature.
However, it gives users ability to detect bugs. It's important gain for
users also.
Wrong code should be fixed anyway. The RFC could be more old code friendly
if E_DEPECATED is used.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
/docs/Web/JavaScript/Reference/Statements/for...in
No. We have foreach for this.
Shells support this syntax, too.
It may be confusing for some users. Good point.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
? Or is there some actual harm you see
caused by it?
Please support the RFC.
Any help/support/improvement/suggestion is appreciated.
As I wrote previously, I think it's not a right time adding this operator
now at least.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
801 - 900 of 1719 matches
Mail list logo
