On Sun, Mar 15, 2015 at 9:56 AM, Leigh <lei...@gmail.com> wrote: > > On 15 March 2015 at 08:42, Pavel Kouřil <pajou...@gmail.com> wrote: >> >> Sure, per-file is better than ini setting, but better doesn't mean >> good (because it is still a pretty bad approach). The ini setting at >> least has the option to be turned off in code once everyone realizes >> it was a bad idea (register_globals via htaccess, for instance), but >> PHP would be stuck with the declare for a long time - this is not an >> easily revertable change, once PHP ships with it. > > > The declaration is turned on with code. This is no different to changing an > ini setting with code, except that it can't be configured globally in > advance. > > Existing code is unaffected. I'm not sure where your "not easily revertible" > argument is grounded. It's incredibly easy to add/remove declarations at the > top of a file. >
So - are you saying that it would be easy to remove this feature from the language once people would realize it's register_globals (and any other settings that change how code behaves) all over again? >> The two groups (people who want strong typing and weak typing) will >> not work *together* though. And it will be a nightmare for everyone >> working on multiple projects from mulitple clients or so. > > > Pure FUD. Sorry but there is no evidence to back this up. > Well, how can there be evidence when the feature isn't released yet? But if you read through the discussions about the Dual Mode RFCs, you'll see that I'm definitely not the only userland developer with this opinion. Also, I can't think of any other language (apart from JS) which has some settings that change how the code behaves. I'd guess most languages don't do this for good reasons, but who knows, can't say for sure. > >> >> The best approach to have some reasonable >> type rules is to progressively "strenghten" the rules (as Zeev's RFC >> tried to do so, but he probably did two steps in one RFC and that's >> what people dislike about it?). > > > You think the best approach is to progressively and continually break > working code between versions? How is this approach acceptable ever? > This of course doesn't mean breaking existing code in every version. I doubt there would be more than 2 or 3 changes to the conversion rules in foreseeable future with this approach. But I do agree that this isn't ideal way to do things, but I'd say it's the right one. >> >> I think that PHP's type system would >> get to some "equilibrium" by this - people wanting stronger typing >> would tried to introduce it and people wanting weaker one would >> balance it and eventually there could be a point on which both sides >> could agree on. > > > No, they would never reach agreement. > "Pure FUD. Sorry but there is no evidence to back this up. " (Sorry, I had to - I really do believe that some consensus would be reached after a while, though.) >> I sincerely hope the Dual Mode RFC doesn't pass. I can't imagine the >> RFC being good for the userland developers in the long run. > > > Apologies again, but I think you don't really understand what is being > proposed in this RFC. Proponents of strict typing get exactly what they > want, they can develop their library or entire project in strict mode if > they want, and if someone wants to use this project or library, but > themselves want to use weak mode, _nothing breaks_. > Why does everyone reply to the disagreeing opinions with "I think you don't understand the RFC"? I've seen this happen multiple times in the discussions with Dual Mode RFC, even when the person understood the RFC. I am 100% aware that the caller decides the rules, not the callee and that there's supposed to be interoperability - and yet, I still strongly disagree with it, mostly because it makes managing multiple projects (each working with different mode) harder. I would generally love to have type hints in PHP 7.0 (with any reasonable ruleset, be it strongly typed, weakly typed or some middle ground, I don't care as long as it's only *one* ruleset), but I would rather have none than the Dual Mode one. Regards Pavel Kouril -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
