# About declare(strict_types = 1) - Thread: https://externals.io/message/84982 - Original archive: https://news-web.php.net/php.internals/84982 - Started by Xinchen Hui on 2015-03-16T05:28:58+00:00 - Messages: 46 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/84982.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #84982 — Xinchen Hui — 2015-03-16T05:28:58+00:00 URL: https://externals.io/message/84982#84982 Hey: The most unaccept feature in current STH thing(v.5.0) is this. acutaly, I believe in most applications, they will still keep this off.. so why we introduce such thing? beside this, I have a question, which is not explained in the RFC: lib.php assuming lib.php is a thrid part library which I want to use it in my project. but I use whole weak types in my project.. thus I simply call add by: that means, I need to add a lots of (int) while I try to call a function in a library which is not written by myself. is that right? thanks -- Xinchen Hui @Laruence http://www.laruence.com/ --- ## #84984 — Dennis Birkholz — 2015-03-16T05:49:59+00:00 URL: https://externals.io/message/84982#84984 · In reply to: #84982 Hello Xinchen, Am 16.03.2015 um 06:28 schrieb Xinchen Hui: > lib.php > declare(strict_types = 1); > function add(int $a, int $b) { > } > > add($_GET['a'], $_GET['b']); > > that means, I need to add a lots of (int) while I try to call a > function in a library which is not written by myself. that is not right and has been discussed a thousand times over. The declare changes the rules only for function calls in the file it is declared in. so: lib.php: The declare here does just nothing. Very easy, explained a thousand times over. Bringing up the same false arguments up again and again does really not help the discussion. Greets Dennis --- ## #84985 — Xinchen Hui — 2015-03-16T05:55:47+00:00 URL: https://externals.io/message/84982#84985 · In reply to: #84984 Hey: > Hello Xinchen, > > Am 16.03.2015 um 06:28 schrieb Xinchen Hui: > > […] > > that is not right and has been discussed a thousand times over. > The declare changes the rules only for function calls in the file it is > declared in. > > so: > lib.php: > declare(strict_types = 1); > function foo(int $a) { > // no function call here > } > ?> > The declare here does just nothing. > > require "lib.php"; > foo("123"); // will work > ?> > > declare(strict_types = 1); > require "lib.php"; > foo("123"); // will give an error > ?> > > Very easy, explained a thousand times over. Bringing up the same false > arguments up again and again does really not help the discussion. That is why I don't see it before (thousand times, too long to read... but not in RFC) anyway, thanks for answering then I have no further questions anymore. thanks > > Greets > Dennis > > > > > > -- > > -- Xinchen Hui @Laruence http://www.laruence.com/ --- ## #84987 — Matthew Leverton — 2015-03-16T06:03:37+00:00 URL: https://externals.io/message/84982#84987 · In reply to: #84985 > That is why I don't see it before (thousand times, too long to read... > but not in RFC) > It's in the RFC: "Whether or not the function being called was declared in a file that uses strict or weak type checking is irrelevant. The type checking mode depends on the file where the function is called." If it were the other way around, then you'd be correct -- it would be a disaster. -- Matthew Leverton --- ## #84990 — Yasuo Ohgaki — 2015-03-16T06:22:23+00:00 URL: https://externals.io/message/84982#84990 · In reply to: #84987 Hi all, On Mon, Mar 16, 2015 at 3:03 PM, Matthew Leverton wrote: > > > […] > It's in the RFC: "Whether or not the function being called was > declared in a file that uses strict or weak type checking is > irrelevant. The type checking mode depends on the file where the > function is called." > This is one of the point I most dislike. Caller _must_ satisfy callee requirements. This is simple principle to write a secure code. 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 yohgaki@ohgaki.net --- ## #84989 — Xinchen Hui — 2015-03-16T06:22:31+00:00 URL: https://externals.io/message/84982#84989 · In reply to: #84987 Hey: > > > […] > It's in the RFC: "Whether or not the function being called was > declared in a file that uses strict or weak type checking is > irrelevant. The type checking mode depends on the file where the > function is called." my fault, I must oversight of reading this... thanks > > If it were the other way around, then you'd be correct -- it would be > a disaster. > > -- > Matthew Leverton -- Xinchen Hui @Laruence http://www.laruence.com/ --- ## #84992 — Dennis Birkholz — 2015-03-16T06:33:47+00:00 URL: https://externals.io/message/84982#84992 · In reply to: #84990 Hi Yasuo, 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. This means > scripts > that are prepared for type safety is "ignored" and it leads security breach. that is simply not true! The callee always gets the type it expects. There is no security problem involved here. The only difference is if type conversion rules apply or if an error is raised for a type mismatch. You clearly dislike the RFC (you voted no), that is OK, but don't scream of "security" bugs that don't exist. If they would exist, all type hint RFCs would have them in general. Greets, Dennis --- ## #84999 — Yasuo Ohgaki — 2015-03-16T07:45:13+00:00 URL: https://externals.io/message/84982#84999 · In reply to: #84992 Hi Dennis, On Mon, Mar 16, 2015 at 3:33 PM, Dennis Birkholz wrote: > Am 16.03.2015 um 07:22 schrieb Yasuo Ohgaki: > > […] > breach. > > that is simply not true! The callee always gets the type it expects. > There is no security problem involved here. The only difference is if > type conversion rules apply or if an error is raised for a type mismatch. > > You clearly dislike the RFC (you voted no), that is OK, but don't scream > of "security" bugs that don't exist. If they would exist, all type hint > RFCs would have them in general. > Not only Java/etc programmers but also PHP programmers will assume type safety by types. Programmers assume integer type data is safe once it passes as integer type parameter. I'm sure PHP programmer do assume the same thing. I posted "bad code" 100) trigger_error('Invalid range'); } // Somewhere far from function definition. $num = $GET['num']; // Somewhere far from $num definition. check_num_range($num); // Trying to check validity, int and range. echo 'You have '.$num. ' now
'; // But $num could have any string. // "check_num_range((int)$num)" wouldn't help also. ?> Caller controlled strict typing makes this worse... i.e. 100) trigger_error('Invalid range'); } ?> Setting register_globals=On while callee script assumes register_globals=Off is bad thing to do. Similar argument applies to declare(strict_types=1) also. As I suggested in other thread, we are better to sit down and make reasonable decision. It's not religion, but technical issue. We can reach reasonable consensus if we try to. If we cannot, it is better to introduce weak type hint only for the time being. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #85001 — Pierre Joye — 2015-03-16T08:17:44+00:00 URL: https://externals.io/message/84982#85001 · In reply to: #84999 > > Hi Dennis, > > On Mon, Mar 16, 2015 at 3:33 PM, Dennis Birkholz > wrote: > > > […] mismatch. > > […] > > Not only Java/etc programmers but also PHP programmers will assume type > safety by types. > > Programmers assume integer type data is safe once it passes as integer type > parameter. > I'm sure PHP programmer do assume the same thing. > > I posted "bad code" > > function check_num_range(int $num) { if ($num < 0 || $num > 100) > trigger_error('Invalid range'); } > // Somewhere far from function definition. > $num = $GET['num']; > // Somewhere far from $num definition. > check_num_range($num); // Trying to check validity, int and range. > echo 'You have '.$num. ' now
'; // But $num could have any string. > // > "check_num_range((int)$num)" wouldn't help also. > ?> > > Caller controlled strict typing makes this worse... i.e. > declare(strict_types=1); > // We are safe since $num is strictly int. Callee has responsibility to > pass valid int . (But it's not) > function check_num_range(int $num) { if ($num < 0 || $num > 100) > trigger_error('Invalid range'); } > ?> > > Setting register_globals=On while callee script assumes > register_globals=Off is bad thing to do. > Similar argument applies to declare(strict_types=1) also. > > As I suggested in other thread, we are better to sit down and make > reasonable decision. > It's not religion, but technical issue. We can reach reasonable consensus > if we try to. If we > cannot, it is better to introduce weak type hint only for the time being. So basically you mixed topics and voted no for the one RFC that would allow what you want to do later while allowing strict hinting already. Accepting the other means changing casting rules again later at best. Not sure you did well here ;-) --- ## #85002 — Lester Caine — 2015-03-16T08:28:25+00:00 URL: https://externals.io/message/84982#85002 · In reply to: #84989 > > […] > my fault, I must oversight of reading this... If the third party library has been 'converted' to strict, and is expecting strict typing to pick up the sort of conversions that the strict camp want to protect against then there are handlers for that error, but if it is called from a situation where weak conversions are all that is being passed would it be necessary to add back in weak error handling as well if the library is not actually designed to handle those cases? I know all of this has been said a thousand times, but we do not CURRENTLY have type hinting, if projects are going to start relying on weak hinting or strict hinting, then is there any guarantee that there will not be new edge cases when mixing the two methods of working. Add in the fact that we do not HAVE to use it so the calling project may simply not be bothering about hinting at all? But now has to handle new errors which start when a library adds any hinting? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #85008 — Pierre Joye — 2015-03-16T09:00:43+00:00 URL: https://externals.io/message/84982#85008 · In reply to: #84982 Hi, > > Hey: > > The most unaccept feature in current STH thing(v.5.0) is this. > > acutaly, I believe in most applications, they will still keep this off.. > > so why we introduce such thing? > > beside this, I have a question, which is not explained in the RFC: > > lib.php > declare(strict_types = 1); > function add(int $a, int $b) { > } > ?> > > assuming lib.php is a thrid part library which I want to use it > in my project. > > but I use whole weak types in my project.. > > thus I simply call add by: > > > add($_GET['a'], $_GET['b']); //recoverable error since all > input in _GET _POST is string by default > > ?> > > that means, I need to add a lots of (int) while I try to call a > function in a library which is not written by myself. > > is that right? You got the answer but one thing bothers me a lot right now. How did you vote against this rfc while missing the core point of it (after actually having a strict mode)? --- ## #85009 — Xinchen Hui — 2015-03-16T09:05:21+00:00 URL: https://externals.io/message/84982#85009 · In reply to: #85008 Hey: > Hi, > > > > […] > > You got the answer but one thing bothers me a lot right now. > > How did you vote against this rfc while missing the core point of it (after > actually having a strict mode)? as I said, " acutaly, I believe in most applications, they will still keep this off.. so why we introduce such thing? " I don't like strict_types at all.. the question I asked is just want one of my concern is not ture, or not oversight by others. thanks -- Xinchen Hui @Laruence http://www.laruence.com/ --- ## #85021 — Yasuo Ohgaki — 2015-03-16T10:59:38+00:00 URL: https://externals.io/message/84982#85021 · In reply to: #85001 Hi Pierre, > > > […] > to > > […] > mismatch. > > […] > scream > > […] > type > > […] > > So basically you mixed topics and voted no for the one RFC that would > allow what you want to do later while allowing strict hinting already. > Accepting the other means changing casting rules again later at best. Not > sure you did well here ;-) > I thought majority of us see the benefit of StrictSTH over this RFC. You're right about it. This RFC will have serious consequence. We made mistake with "safe_mode". The main reason it failed is "it did not force caller to have responsibility to make it work as it should". This RFC does the same for how declare(strict_types=1) works. Aren't we learned from "safe_mode" lessons? Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #85022 — Dan Ackroyd — 2015-03-16T11:15:53+00:00 URL: https://externals.io/message/84982#85022 · In reply to: #85009 > Hey: > I don't like strict_types at all.. > And you would never be forced to use them. But you're voting against allowing anyone else to use them. :-( cheers Dan --- ## #85024 — Derick Rethans — 2015-03-16T11:18:34+00:00 URL: https://externals.io/message/84982#85024 · In reply to: #85009 > > > […] > as I said, > " > acutaly, I believe in most applications, they will still keep this off.. > > so why we introduce such thing? > " > I don't like strict_types at all.. To be frank, I don't think "I don't like this" is a terribly good reason to vote against (or for something). What is important is how many people would actually benefit from a feature, without it causing issues for others. I am certainly no fan of the "declare" *syntax*, but I do know, from talking at conferences that many many developers would like to see scalar type hints in some way — both weak (mode 1 of the STHv5 RFC), and strict (mode 2). It even caters for people that don't want to use them at all, as they can simply not use them. I also know, that without a dual mode, it seems very unlikely for scalar type hints to make it into PHP 7, and I don't think that is what users want. As this is our *best* bet, I can only vote "yes". cheers, Derick --- ## #85025 — Derick Rethans — 2015-03-16T11:30:49+00:00 URL: https://externals.io/message/84982#85025 · In reply to: #85021 > > > > […] That's not true. The caller does not override any security setting. The receiving function (callee) will *always* get the type they declared. *That* is important for security. When I first saw Andrea's v3, I was also of the opinion that it should be the callee that controls whether the type hints should be strict or not. But then I realized that it *does not matter*, as the callee will get the right type regardless. Allowing the caller to decide whether it throws an error or not, is irrelevant to any sort of security. Realizing that it didn't matter, made me change my "no" vote to "yes". > I thought majority of us see the benefit of StrictSTH over this RFC. > You're right about it. > > This RFC will have serious consequence. We made mistake with > "safe_mode". The main reason it failed is "it did not force caller to > have responsibility to make it work as it should". This RFC does the > same for how declare(strict_types=1) works. > > Aren't we learned from "safe_mode" lessons? I am not sure why you mention "safe_mode" as this has absolutely nothing to do with scalar type hints. Not feature wise, not implementation wise. safe_mode, first of all, was a global INI setting. The developer couldn't turn it off easily. That was probably at least 80% of the pain. The second part was the name, as it indicated that it made your scripts safe: It didn't. STHv5 does not suffer from either issue — developers can pick and choose the best solution for *them* (give them some credit, most developers are actually smart!). Library authors always get the right type if they type hint, which is *their* main pain point. And the type names have always already been used for casts anyway, and don't include "safe" in their name. cheers, Derick --- ## #85026 — Xinchen Hui — 2015-03-16T11:32:23+00:00 URL: https://externals.io/message/84982#85026 · In reply to: #85024 Hey: > > > > […] > > > […] > > To be frank, I don't think "I don't like this" is a terribly good reason > to vote against (or for something). What is important is how many people > would actually benefit from a feature, without it causing issues for > others. I am certainly no fan of the "declare" *syntax*, but I do know, > from talking at conferences that many many developers would like to see > scalar type hints in some way — both weak (mode 1 of the STHv5 RFC), and I think they just want a weak type hintings(PHP is a weak type language).. not strict types. especially not a dual mode, switch on/off by a declare line.. it looks so ugly to me.. > strict (mode 2). It even caters for people that don't want to use them > at all, as they can simply not use them. I also know, that without a > dual mode, it seems very unlikely for scalar type hints to make it > into PHP 7, and I don't think that is what users want. As this is our > *best* bet, I can only vote "yes". I understand your choice, but for me, as a six year PHP user. I can see how strict types can benifit me.. the only usage I can image is, turn on it in developer env to clean types passing, and turn off in produce env for safety(in case I forget to cast some types from $_GET $_POST). which is definitlely can be done by a extension, or hook.. thanks > > cheers, > Derick -- Xinchen Hui @Laruence http://www.laruence.com/ --- ## #85027 — Yasuo Ohgaki — 2015-03-16T11:33:00+00:00 URL: https://externals.io/message/84982#85027 · In reply to: #85024 Hi Derick, > > > > […] > wrote: > > […] > (after > > […] > > > […] > > To be frank, I don't think "I don't like this" is a terribly good reason > to vote against (or for something). What is important is how many people > would actually benefit from a feature, without it causing issues for > others. I am certainly no fan of the "declare" *syntax*, but I do know, > from talking at conferences that many many developers would like to see > scalar type hints in some way — both weak (mode 1 of the STHv5 RFC), and > strict (mode 2). It even caters for people that don't want to use them > at all, as they can simply not use them. I also know, that without a > dual mode, it seems very unlikely for scalar type hints to make it > into PHP 7, and I don't think that is what users want. As this is our > *best* bet, I can only vote "yes". Are you sure on your bet? lib.php: The declare here does just nothing. a.php: b.php: This behavior is unacceptable. Caller (a.php, b.php) must satisfy lib.php expectation to make lib.php work as it should. Otherwise, all kinds of unexpected for lib.php and it's users may happen. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #85028 — Xinchen Hui — 2015-03-16T11:33:38+00:00 URL: https://externals.io/message/84982#85028 · In reply to: #85026 > Hey: > > > > […] > I think they just want a weak type hintings(PHP is a weak type > language).. not strict types. > > especially not a dual mode, switch on/off by a declare line.. > > it looks so ugly to me.. > > > […] > I understand your choice, but for me, as a six year PHP user. I can > see how strict types can benifit me.. can not > > the only usage I can image is, turn on it in developer env to clean > types passing, and turn off in produce env for safety(in case I forget > to cast some types from $_GET $_POST). > > which is definitlely can be done by a extension, or hook.. > > thanks > > […] > > > > -- > Xinchen Hui > @Laruence > http://www.laruence.com/ -- Xinchen Hui @Laruence http://www.laruence.com/ --- ## #85029 — Xinchen Hui — 2015-03-16T11:39:41+00:00 URL: https://externals.io/message/84982#85029 · In reply to: #85027 Hey: > Hi Derick, > > > > […] > > > Are you sure on your bet? > > lib.php: > declare(strict_types = 1); > function foo(int $a) { > // no function call here > } > ?> > The declare here does just nothing. > > a.php: > require "lib.php"; > foo("123"); // will work > ?> > > b.php: > declare(strict_types = 1); > require "lib.php"; > foo("123"); // will give an error > ?> > > This behavior is unacceptable. > Caller (a.php, b.php) must satisfy lib.php expectation to make lib.php > work as it should. Otherwise, all kinds of unexpected for lib.php and it's > users may happen. > > Regards, > > -- > Yasuo Ohgaki > yohgaki@ohgaki.net And last comment, if there no such declare thing, I will definitely vote yes to this RFC. that's why I want vote no for this, and wait for Bob's Basic STH. thanks > -- Xinchen Hui @Laruence http://www.laruence.com/ --- ## #85031 — Nikita Nefedov — 2015-03-16T11:44:49+00:00 URL: https://externals.io/message/84982#85031 · In reply to: #85027 On Mon, 16 Mar 2015 14:33:00 +0300, Yasuo Ohgaki wrote: > Hi Derick, > > > > > […] > > > Are you sure on your bet? > > lib.php: > declare(strict_types = 1); > function foo(int $a) { > // no function call here > } > ?> > The declare here does just nothing. > > a.php: > require "lib.php"; > foo("123"); // will work > ?> > > b.php: > declare(strict_types = 1); > require "lib.php"; > foo("123"); // will give an error > ?> > > This behavior is unacceptable. > Caller (a.php, b.php) must satisfy lib.php expectation to make lib.php > work as it should. Otherwise, all kinds of unexpected for lib.php and > it's > users may happen. When called from a.php, foo() will get and int(123), this is exactly what is expected. Author of a.php acknowledges that all arguments in fcalls from this file will be converted to appropriate types, this is basically how all our internal functions work currently and it's perfectly acceptable. But if you don't want this kind of type juggling then you opt-in strict types. This is basically as easy as it gets, I don't see any way to make it simpler. There's nothing to evolve in this RFC, it covers pretty much everything and the idea of allowing for caller to make a decision is, in my opinion, a great win in this situation. --- ## #85032 — pajousek@gmail.com — 2015-03-16T11:49:44+00:00 URL: https://externals.io/message/84982#85032 · In reply to: #85025 > > […] > > I am not sure why you mention "safe_mode" as this has absolutely nothing > to do with scalar type hints. Not feature wise, not implementation wise. > > safe_mode, first of all, was a global INI setting. The developer > couldn't turn it off easily. That was probably at least 80% of the pain. > The second part was the name, as it indicated that it made your scripts > safe: It didn't. > > STHv5 does not suffer from either issue — developers can pick and choose > the best solution for *them* (give them some credit, most developers are > actually smart!). Library authors always get the right type if they type > hint, which is *their* main pain point. And the type names have always > already been used for casts anyway, and don't include "safe" in their > name. > > cheers, Hello, it's similiar to the safe_mode though. Sure, it's not as bad as INI setting, but the "intent" is the same - a switch changing how code behaves. When I talked about the Dual Mode with some friends who are userland PHP devs (either current or former, because they switched to other stuff), none of them called the Dual Mode a great idea. The responses I got were mostly along the lines of "wow, this seems really weird" to "WTF are those developers smoking". Everyone of them (sure, ~10 people isn't really representative number) said that they think PHP needs STH, but not this Dual Mode stuff. Seriously, think about it for a while - when some setting that changes how code behaves was a good idea? (IMHO never.) Regards Pavel Kouril --- ## #85033 — Yasuo Ohgaki — 2015-03-16T11:50:16+00:00 URL: https://externals.io/message/84982#85033 · In reply to: #85031 > On Mon, 16 Mar 2015 14:33:00 +0300, Yasuo Ohgaki > wrote: > > Hi Derick, > > […] > > When called from a.php, foo() will get and int(123), this is exactly what > is expected. Author of a.php acknowledges that all arguments in fcalls from > this file will be converted to appropriate types, this is basically how all > our internal functions work currently and it's perfectly acceptable. But if > you don't want this kind of type juggling then you opt-in strict types. > This is basically as easy as it gets, I don't see any way to make it > simpler. There's nothing to evolve in this RFC, it covers pretty much > everything and the idea of allowing for caller to make a decision is, in my > opinion, a great win in this situation. I already showed real world example how this could be fail. If we need this kind of behavior. I would suggest to have type affinity like SQLite for $_GET/$_POST/$_COOKIE. https://www.sqlite.org/datatype3.html This would work better to work with strict types. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #85035 — Dan Ackroyd — 2015-03-16T12:04:31+00:00 URL: https://externals.io/message/84982#85035 · In reply to: #85032 > > […] > > Seriously, think about it for a while - when some setting that changes > how code behaves was a good idea? The problem is that there are two irreconcilable camps - some people want weak STHs, other people want strict STHs. This RFC gives both camps what they want, at the cost of having the dual mode. I personally would prefer a single mode, with strict STHs but I can see that would piss off the other camp. And so to me, this RFC even with the ickiness of the setting, is an an acceptable cost to giving both sides what they want. Oh, and people who don't want to use scalar type hints at all, can still continue to not use scalar type hints, and their code will continue to keep working. Anyone who is voting no, isn't doing so because they are missing out on a feature, they're doing it to block other people from getting what they want in PHP, which is just a terrible way to vote. And if the strict camp are wrong and strict scalars are just not used by a large proportion of the PHP community, it would be trivial to remove support for the strict mode in a future version of PHP, as all code that runs in strict mode, will automatically work in weak mode. cheers Dan --- ## #85036 — Jordi Boggiano — 2015-03-16T12:07:31+00:00 URL: https://externals.io/message/84982#85036 · In reply to: #85032 > it's similiar to the safe_mode though. Sure, it's not as bad as INI > setting, but the "intent" is the same - a switch changing how code > behaves. ini_set('memory_limit', 10); also changes how your code behave, but it's global so that can be problematic. die; changes how your code behave, but you can fix it if it doesn't do what you want in your file. Code has meaning and therefore code changes what the program does. I don't think that's really a problem. > When I talked about the Dual Mode with some friends who are userland > PHP devs (either current or former, because they switched to other > stuff), none of them called the Dual Mode a great idea. The responses > I got were mostly along the lines of "wow, this seems really weird" to > "WTF are those developers smoking". Everyone of them (sure, ~10 people > isn't really representative number) said that they think PHP needs > STH, but not this Dual Mode stuff. > > Seriously, think about it for a while - when some setting that changes > how code behaves was a good idea? All your friends can happily ignore strict mode and no sysadmin can enable it as it is per-file. Those of us that do understand it and might want to use it can do so, and if your friends eventually go beyond the "this seems really weird" phase (it *is* weird because it's an uncommon approach to have both strict and non-strict in one language, but that doesn't necessarily mean it's bad) maybe they'll want to use it too some day. Or perhaps they'll need to start smoking. Cheers, Jordi --- Next page: https://externals.io/message/84982.md?page=2