Re: [PHP-DEV] Re: [RFC] Namespace-scoped declares, again
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
Re: [PHP-DEV] Re: [RFC] Explicit call-site send-by-ref syntax
Hi!
>> In short, while currently we have
>>
>> function byRef(&$ref) {...}
>> byRef($var);
>>
>> this proposal would also allow
>>
>> function byRef(&$ref) {...}
>> byRef(&$var);
I am not sure why it is necessary. If you call a function, one would
assume you know what it is doing, at least you know its definition, and
with any modern IDE if you do not, it is a matter of one click (or less)
to reveal what the function does. So what is the point to mark it again?
Does not seem to add anything that the writer or reader doesn't know or
could easily find out.
It could also imply that if the call site does not bear & mark, then the
parameter can not be modified - which is not true (or only true for
primitive values) and would add to the confusion.
> I think it can either go forward as-is, in that it constitutes the first
> step towards bringing sanity to by-reference passing in the long term. Or I
Could you explain what you mean by "bringing sanity to by-reference
passing"? Maybe if it would be clearer what you're getting at, in that
context this proposal would be more understandable.
> could first try to push through
> https://wiki.php.net/rfc/namespace_scoped_declares or some variant thereof
> so that call-site reference passing annotations can be made required on a
> per-library/project basis.
That certainly would be very annoying and I would be very much against
it (and in general against the idea of fragmenting the language into a
thousand of tiny pieces with different syntax by adding more and more
local syntax-changing options) but I think this should be discussed
separately so I'll say no more here.
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Explicit call-site send-by-ref syntax
Hi! > I think nowadays it is well known that by-reference passing is to be > avoided and I don't see it particularly commonly in user code. By-reference I don't think it's true. It depends on the style of coding, of course, but there are many situations where the most convenient solution is by-ref passing, mostly when single function can change more than one thing. Of course there are ways around it, but they are less convenient and less intuitive. Additionally, if you want a function to do some mutation with arrays, there's only two ways of doing it - either returning the resulting array (which can double the data) or pass by-ref. Again, there are ways around it, but again they are less convenient. And, if your own argument recognizes internal functions have legitimate reasons to use references, the same comes for user functions too - they could implement similar functionality. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Namespace-scoped declares, again
On 27/07/2019 09:33, Rasmus Schultz wrote: On Thu, Jul 25, 2019 at 3:34 PM Nikita Popov wrote: Based on the received feedback, I plan to change this proposal from being "namespace-scoped" to being "directory-scoped" instead Personally I'm not a huge fan of using implicit hierarchical directories for managing defines. It's certainly better than global state functions, but in general I don't feel comfortable with the idea that an arbitrary file can effect the behaviour of the VM for particular files that does not directly reference it. Obviously there's lots of functions that do that, set_error_handler etc, but I think it is best avoided wherever possible. I think what the situation calls for is the PHP equivalent of #include - we need to be able to explicitly import the definitions from another file. == MyProject\Models\Test\SomeClass.php === ``` Clearly the question is "how to locate that file" as we don't want to return to the days of having to add relative file paths to every file. An option which immediately comes to mind would be a new autoloader routine that maps namespaces to PSR4 physical directories. Sounds like a job for composer tbh so userland workload would be limited for projects using modern workflows. This would of course be dependent on if the compiler stage has the ability to branch off and call an autoloader the first time it encounters the import_declares. Just my 2 pence worth. -- Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Namespace-scoped declares, again
On Thu, Jul 25, 2019 at 3:34 PM Nikita Popov wrote: ... > Based on the received feedback, I plan to change this proposal from being > "namespace-scoped" to being "directory-scoped" instead ... I think that's a better approach. But please consider doing this without adding another global function that defines more global (compiler) state? If it's going to be directory-scoped, using some kind of project root file, in my opinion, is the more traditional way to declare directory-scoped boundaries. For example, if you could just put a "php.json" file in the root of your namespace folder, this becomes very easy to spot next to your ".gitignore", "composer.json", "package.json", "tsconfig.json" and any other well-known project configuration files. Finding these in the root of any project/library is pretty intuitive - poking through bootstrapping scripts for a global function call, meh, not so much. (This file could be used to declare other repetitive things too - for one, why is the declare() situation any different from having to repeat a namespace declaration in every file? This is just another global setting that could just as well be declared once in a project root file. If this file were parsable or reflectable by e.g. Composer, this could probably be used to make the "autoload" section in Composer optional, for one.) (You could expand upon this feature in the future to add other compiler options - for instance, toggling global functions, which would allow for things like correcting inconsistent argument order in the standard libraries, toggling incompatible language features, toggling improved defaults for certain functions, a proper strict type-checking mode at some point in the future, etc...)
