Hi! > I plan to pick up this proposal again. I think the motivation here has > become more pressing in the meantime. The strict_operators proposal is > under discussion, and Rowan's "locked classes" essentially concluded with > "doing this with a declare is better". I also think that this proposal will > be helpful for the explicit call-site by-reference passing RFC.
I think it's a wrong way to make semantics of the language to be different in different libraries. We add one option, than another, than another, and soon we have 512 variants of the language, all slightly different, and you have to keep track which one you are dealing with on each file, and God forbid you move a piece of code from one library to another, you have to rewrite half of it because it was written in PHP #243 but this library is actually PHP #116. I know there is not a consensus about usage of some newly proposed language features. I think introducing this kind of fragmentation to deal with it is exactly wrong way to deal with it. It leads to code from different codebases being incompatible with each other on source level (even if they work together at runtime). We've decided not to do INI options to change language behavior, and I think we should also not make declare() options to change language behavior, because they are - especially when applying to more than local file - essentially low-grade INI options. They create non-local context that changes behavior of the language, and they make it impossible, reading the local code, to know what it actually means and what would happen if you run it. I think it's much better for the language not to have some features than to fragment the language and make it incompatible with itself. > Based on the received feedback, I plan to change this proposal from being > "namespace-scoped" to being "directory-scoped" instead. This should both I don't think it improves much, in my opinion, and it also introduces hard dependency in the language on specific placing of files and directories - i.e. if you move file on the filesystem, it can actually work differently, which was never the case before. Having concepts like filenames change the core functionality of the language looks to me like an example of leaky abstraction and a hack which may solve a particular problem now but at the cost of making the whole design more messy and introducing more problems in the future. I said before that moving code between libraries in this setup could break it - but with this change, even copying a file to a different directory may break it! Moreover, change in one part of project, changing some behavioral option, would propagate and influence code about which the changer may not even know (e.g. if parts of the project are developed and tested separately and only deployed in final form on a production filesystem). This looks like potential to create an environment that is very hard to navigate and keep straight which of the options is in play for each peace of code. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
