> On 09/08/2016 21:26, Fleshgrinder wrote:
>> An alternative approach could be to auto-load only namespaced
>> things and leave non-namespaced stuff alone.
>
> It's not quite as simple as that, as examples have already shown.
>
> # file a.php namespace Acme\Foo; function a() { return 'Hello
> World'; }
>
> # file b.php namespace Acme\Foo; function b() { $message = a(); #
> this is a call to Acme\Foo\a return strpos($message, 'Hello'); # this
> is a call to \strpos }
>
>
> There's no way of telling that the a() is namespaced and the
> strpos()
> is global until *after* the autoloader has run. There *might* be a
> function Acme\Foo\strpos which is autoloadable.
>
> Regards,Absolutely true yeah. I guess there's nothing to be done about this without calling the auto-loader all the time plus implementing some caching. On 8/10/2016 10:58 AM, Stanislav Malyshev wrote: > Hi! > >> Having the use statement trigger the auto-loader would result in a lot >> of broken code because of optional dependencies (remember the examples I >> showed you in the annotation thread). > > I think it's not a good idea in general. use statement right now is > basically a syntax sugar - you just change interpretation of names. But > you don't cause anything to load by this statement. Changing it would > mean people have to change a lot of assumptions about what is loaded > when. E.g., there's a lot of code which use's classes and spaces that > may not even exist - just because they *might* exist in some scenarios, > and will be used in those scenarios, further down in the code. > > I don't think completely changing the semantics of a very widely used > statement is anything we should be doing. > Ibid. On 8/10/2016 10:58 AM, Stanislav Malyshev wrote: >> This would make it even more painful for users to define anything in the >> global namespace; a good thing. > > No it's not. Why should it be a good thing? > Defining anything in the global namespace in userland code is not bad per se. It just creates potential for name collisions in future PHP versions if future PHP versions introduce anything that has the same name. I did not say that we should actively discourage people to define things in the global namespace, on the contrary since having the ability to use this is a core part of PHP, but it would make people more sensible while doing so for their own good. Which is a good thing in my opinion. On 8/10/2016 10:58 AM, Stanislav Malyshev wrote: >> It would however encourage people to prefix their stuff inline with a >> backslash, otherwise you end up with an endless use chain for every > > I'm sorry but this is horrible. PHP code should not look like a fence of > backslashes, backslashes do not have any useful function there and in > 99.9999% of cases global functions *are* global functions, and nobody is > overriding them. Yes, you can override strlen. No, nobody (within > 0.00001% accuracy) does. > I agree completely and I am afraid of the backslash fence as well, extremely to be honest. On 8/10/2016 10:58 AM, Stanislav Malyshev wrote: >> built-in feature which is not nice. That being said, it's required >> anyways if we are really going to introduce namespaces for everything >> within PHP (e.g. `use function php\random_bytes;`). Something I still >> think is a bad idea at least for procedural first-level functions. > > It's a bad idea for all existing functions and classes. Because it adds > complications for people without giving them anything in exchange. > Ibid. -- Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
