4 ms·

You can `use Illuminate\Mail as Mailer` if you want

by _def 5y ago

TekMol 5y ago
That is not what I mean. It would not prevent a clash with another "Illuminate" namespace. The problem is that the developer of "Illuminate\Mail" had to introduce the "Illuminate" namespace and hope nobody else uses it. Additionally it makes the code more complex. Every file needs to carry this "namespace ...." line now.
- ainiriand 5y ago
  You can hope all you want but you won't be able to submit any duplicated namespace to Packagist.
  - TekMol 5y ago
    That is another consequence I don't like about the quirky namespace approach. It collects more and more problems like a ball of dust that gets bigger and bigger. The consequence you mention is that one depends more and more on tooling and services.
    - CR007 5y ago
      Did you actually get these issues in a real use case? I've been developing PHP software for +15 years and I never had this namespace dilema.
      - TekMol 5y ago
        But you suffer the indirections caused by the fat stack that is needed to deal with the missing import system. In Python, "import" actually imports the code. In PHP, the "use" statement you see everywhere does not. It only works because the code has already "magically" been imported. Usually by composer. Thats why there are tens of thousands of hits for "clear composer cache" on Google. To just point out one issue with the dependecy on a fat stack to deal with a missing import system.
        CR007 5y ago
        The fact that composer comes with an autoloader doesn't means that you have to autoload everything. You can manual include, define your own extra auto loader and use interfaces to quick swap for custom implementations. Like I said, +15 years. Composer is 9 years old. How do you think we handle this in our own Jurassic times?
        TekMol 5y ago
        You can manual include I don't think that will work with any code that came out in recent years. Because it all expects that its dependencies are automagically included via composer. In practice, every PHP based web application starts with Laravel or Symfony these days. So you are thrown into the composer workflow right away. And it would be a nightmare to fight it.
        CR007 5y ago
        Nope. I don't use these frameworks. But thanks for trying to assume how php is on 2022 and how all php devs work.
        TekMol 5y ago
        How do you build web applications these days?
        ihateolives 5y ago
        Web applications come in all shapes and sizes. If you have an application that just mediates data from database and exposes API to frontend then for couple of endpoints you don't even need router or any other packages, PHP has lots of stuff baked in. You just check if the request is GET/POST/PUT/DELETE/PATCH, work with data, output a header 'Content-Type: application/json', send the data and be done with it. Or output a html template with data or whatever. Or you can not use templates and mash it all together in PHP which already is a templating language. You can do it as simple or complicated as you need. And then if you start needing additional functionality you can start adding packages with composer one by one. Of course it'd be stupid to build your own version of Symfony with it, but the beauty is that you can stop at any point you want if it covers your needs. This sort of thing would be much more hassle with say Java, without using any frameworks.
    - captn3m0 5y ago
      The autoloader in composer offers several alternatives, and while all of them are namespaced per convention - nothing stops a project from deciding to write their own - something super easy in PHP but impossibly hard in other languages. I find PHP packaging and dependency management to be painless compared to both Python/Ruby.
  - rbanffy 5y ago
    Java solved this by using domain names as unique identifiers. I can use com.banffy and be sure only a complete a*hole would make a package in this space.
    - jwdunne 5y ago
      This is roughly PHP’s approach. In this case, Illuminate is the vendor prefix and Mail is the package name. This often but not always corresponds to the rules around the composer package name, which would be illuminate/mail in this case. This is similar to NPM’s organisation prefix (@foo/bar). But yeah, I’m not defending the hacky way namespaces are resolved through autoloading. I do prefer actual language support for a module system (but Ruby suffers from this problem too).
      - captn3m0 5y ago
        I actually prefer auto-loading, which lets you iterate through a package manager much easier/faster - PHP iterated through PSR-0[0] before landing on PSR-4[1], and you can always build your own (which is what most frameworks pre-composer were doing). With Rails 7 and Zeitwerk, the Ruby community has landed on a very similar auto-loading system as PHP now[2] with constants translating to paths by convention. [0]: https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-0.md https://github.com/php-fig/fig-standards/blob/master/accepte... [1]: https://www.php-fig.org/psr/psr-4/ https://www.php-fig.org/psr/psr-4/ [2]: https://github.com/fxn/zeitwerk#the-idea-file-paths-match-constant-paths https://github.com/fxn/zeitwerk#the-idea-file-paths-match-co...
        jwdunne 5y ago
        Yeah, I prefer an actual module system over PHP namespaces plus autoloader. It feels like a hacked on module system tbf. BUT I do get lots of real work done using namespaces and a PSR autoloader so it works. I do wish they would extend auto loading for standalone functions and constants though.

You can `use Illuminate\Mail as Mailer` if you want

by _def 5y ago

You can `use Illuminate\Mail as Mailer` if you want

That is not what I mean. It would not prevent a clash with another "Illuminate" namespace. The problem is that the developer of "Illuminate\Mail" had to introduce the "Illuminate" namespace and hope nobody else uses it. Additionally it makes the code more complex. Every file needs to carry this "namespace ...." line now.

ainiriand 5y ago
You can hope all you want but you won't be able to submit any duplicated namespace to Packagist.
- TekMol 5y ago
  That is another consequence I don't like about the quirky namespace approach. It collects more and more problems like a ball of dust that gets bigger and bigger. The consequence you mention is that one depends more and more on tooling and services.
  - CR007 5y ago
    Did you actually get these issues in a real use case? I've been developing PHP software for +15 years and I never had this namespace dilema.
    - TekMol 5y ago
      But you suffer the indirections caused by the fat stack that is needed to deal with the missing import system. In Python, "import" actually imports the code. In PHP, the "use" statement you see everywhere does not. It only works because the code has already "magically" been imported. Usually by composer. Thats why there are tens of thousands of hits for "clear composer cache" on Google. To just point out one issue with the dependecy on a fat stack to deal with a missing import system.
      - CR007 5y ago
        The fact that composer comes with an autoloader doesn't means that you have to autoload everything. You can manual include, define your own extra auto loader and use interfaces to quick swap for custom implementations. Like I said, +15 years. Composer is 9 years old. How do you think we handle this in our own Jurassic times?
        TekMol 5y ago
        You can manual include I don't think that will work with any code that came out in recent years. Because it all expects that its dependencies are automagically included via composer. In practice, every PHP based web application starts with Laravel or Symfony these days. So you are thrown into the composer workflow right away. And it would be a nightmare to fight it.
        CR007 5y ago
        Nope. I don't use these frameworks. But thanks for trying to assume how php is on 2022 and how all php devs work.
        TekMol 5y ago
        How do you build web applications these days?
        ihateolives 5y ago
        Web applications come in all shapes and sizes. If you have an application that just mediates data from database and exposes API to frontend then for couple of endpoints you don't even need router or any other packages, PHP has lots of stuff baked in. You just check if the request is GET/POST/PUT/DELETE/PATCH, work with data, output a header 'Content-Type: application/json', send the data and be done with it. Or output a html template with data or whatever. Or you can not use templates and mash it all together in PHP which already is a templating language. You can do it as simple or complicated as you need. And then if you start needing additional functionality you can start adding packages with composer one by one. Of course it'd be stupid to build your own version of Symfony with it, but the beauty is that you can stop at any point you want if it covers your needs. This sort of thing would be much more hassle with say Java, without using any frameworks.
  - captn3m0 5y ago
    The autoloader in composer offers several alternatives, and while all of them are namespaced per convention - nothing stops a project from deciding to write their own - something super easy in PHP but impossibly hard in other languages. I find PHP packaging and dependency management to be painless compared to both Python/Ruby.
- rbanffy 5y ago
  Java solved this by using domain names as unique identifiers. I can use com.banffy and be sure only a complete a*hole would make a package in this space.
  - jwdunne 5y ago
    This is roughly PHP’s approach. In this case, Illuminate is the vendor prefix and Mail is the package name. This often but not always corresponds to the rules around the composer package name, which would be illuminate/mail in this case. This is similar to NPM’s organisation prefix (@foo/bar). But yeah, I’m not defending the hacky way namespaces are resolved through autoloading. I do prefer actual language support for a module system (but Ruby suffers from this problem too).
    - captn3m0 5y ago
      I actually prefer auto-loading, which lets you iterate through a package manager much easier/faster - PHP iterated through PSR-0[0] before landing on PSR-4[1], and you can always build your own (which is what most frameworks pre-composer were doing). With Rails 7 and Zeitwerk, the Ruby community has landed on a very similar auto-loading system as PHP now[2] with constants translating to paths by convention. [0]: https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-0.md https://github.com/php-fig/fig-standards/blob/master/accepte... [1]: https://www.php-fig.org/psr/psr-4/ https://www.php-fig.org/psr/psr-4/ [2]: https://github.com/fxn/zeitwerk#the-idea-file-paths-match-constant-paths https://github.com/fxn/zeitwerk#the-idea-file-paths-match-co...
      - jwdunne 5y ago
        Yeah, I prefer an actual module system over PHP namespaces plus autoloader. It feels like a hacked on module system tbf. BUT I do get lots of real work done using namespaces and a PSR autoloader so it works. I do wish they would extend auto loading for standalone functions and constants though.