On Sun, 16 Jun 2024 at 20:08, Rowan Tommins [IMSoP] <imsop....@rwec.co.uk> wrote: > > On 16/06/2024 18:54, Andreas Hennings wrote: > > Yes, the possibility for namespace part imports exists. > Unfortunately these namespace imports usually need to be set up > manually, whereas the regular class or function import has better > automatic support from the IDE. > Also, namespace fragments are often more generic than function names, > so more likely to need a custom alias. > > > That's why I said it was tricky: the language doesn't prevent IDEs suggesting > different imports; nor does it require you to name namespace fragments > differently from classes; but that's what happens in practice.
Right. The main thing here would be to have a 90% deterministic way to generate the imports. We want to avoid meaningless choices a developer needs to make case by case. I see some difficulties here, but there are probably ways to handle it. > So to what extent do we build the language based on how it *can* be used, and > to what extent do we build it based on how it *is* used? What if that usage > changes over time? What if we add more ways to do it, and those aren't used > either? I don't think there's an easy answer. It depends how disruptive the change is. E.g. symfony has a Yaml class with only class constants and static methods. https://github.com/symfony/symfony/blob/35890e1ca999cb92d7b20c81bc07cdc2f17b7bb4/src/Symfony/Component/Yaml/Yaml.php We can argue whether this is good or bad. Or we can just slap a "static" modifier on the class, so that developers know what to expect. This does not prevent future refactoring, where these methods might be converted to functions. Btw, even with only the class constants left, this would still be an all-static class.
