4 ms·

So the author considers following PSR guidelines beyond 1 and 2 to be "the wrong way"? PSR-4 is the currently accepted best practice for autoloading and while

by jpnave 10y ago

So the author considers following PSR guidelines beyond 1 and 2 to be "the wrong way"? PSR-4 is the currently accepted best practice for autoloading and while it "may [have] a direct effect upon how you code your software," it's the optimal approach for 99% of projects I've encountered. Following community interoperability guidelines is what allows developers to move away from monolithic frameworks and compose projects based on the packages they need.

stephenr 10y ago
> currently accepted best practice for autoloading According to who? FIG? Are you aware that php has a built in auto loader that supports namespaces and is written in C? > compose projects based on the packages they need. Ah, the NPM/Composer golden brick road to development. Aka, the "I don't know what this is but I'm gonna lick it" approach to development, where you end up with 50 "micro-frameworks" or "utility libraries" each of which depends on a further 20 other libraries. I have some issues with this site but it's right that the FIG is a joke, and anyone who claims its "best practice" is not paying attention.
- mgkimsal 10y ago
  > Are you aware that php has a built in auto loader that supports namespaces and is written in C? What are you referring to?
  - kijin 10y ago
    Probably spl_autoload [1]. [1] https://secure.php.net/manual/en/function.spl-autoload.php https://secure.php.net/manual/en/function.spl-autoload.php
    - mgkimsal 10y ago
      that's what I thought poster might have meant, but.... it's not an autoloader, it's a way of registering autoloader code.
      - stephenr 10y ago
        You're thinking of spl_autoload_register. spl_autoload absolutely is an autoloader, and it is registered via spl_autoload_register.
- jpnave 10y ago
  > According to who? FIG? According to the vast majority of authors of the most widely used and tested PHP libararies. > Are you aware that php has a built in auto loader that supports namespaces and is written in C? You mean the autoloader builtins that composer uses under the hood already? This is better than a 1 line include how exactly? > Ah, the NPM/Composer golden brick road to development. Aka, the "I don't know what this is but I'm gonna lick it" approach to development I don't understand what you're saying here, everyone should be writing their own libraries from scratch? It has always been up to the developer to vet the dependencies they choose to include in their project. That applies to every language ecosystem, not just Node.
  - stephenr 10y ago
    > According to the vast majority of authors of the most widely used and tested PHP libararies. So, FIG. "Group of developers say that groups' work is the best. News at 11." > You mean the autoloader builtins that composer uses under the hood already? No, spl_autoload is a working namespace aware autoloader. Composer uses a bunch of userland code. > I don't understand what you're saying here, everyone should be writing their own libraries from scratch? Did I say that? I've seen, multiple times the negative consequences of the current fad to rely on 25 separate, single-purpose 3rd party Libs, all of which are basic functionality that a well thought out library would give you, but with the added "bonus" of each relying on 20 other libraries to do basic things. > It has always been up to the developer to vet the dependencies they choose to include in their project. That applies to every language ecosystem, not just Node. Do the vast majority of developers know that? Because the ones I've had the "pleasure" of working with, definitely don't.

by jpnave 10y ago

stephenr 10y ago

> currently accepted best practice for autoloading According to who? FIG? Are you aware that php has a built in auto loader that supports namespaces and is written in C? > compose projects based on the packages they need. Ah, the NPM/Composer golden brick road to development. Aka, the "I don't know what this is but I'm gonna lick it" approach to development, where you end up with 50 "micro-frameworks" or "utility libraries" each of which depends on a further 20 other libraries. I have some issues with this site but it's right that the FIG is a joke, and anyone who claims its "best practice" is not paying attention.

mgkimsal 10y ago
> Are you aware that php has a built in auto loader that supports namespaces and is written in C? What are you referring to?
- kijin 10y ago
  Probably spl_autoload [1]. [1] https://secure.php.net/manual/en/function.spl-autoload.php https://secure.php.net/manual/en/function.spl-autoload.php
  - mgkimsal 10y ago
    that's what I thought poster might have meant, but.... it's not an autoloader, it's a way of registering autoloader code.
    - stephenr 10y ago
      You're thinking of spl_autoload_register. spl_autoload absolutely is an autoloader, and it is registered via spl_autoload_register.
jpnave 10y ago
> According to who? FIG? According to the vast majority of authors of the most widely used and tested PHP libararies. > Are you aware that php has a built in auto loader that supports namespaces and is written in C? You mean the autoloader builtins that composer uses under the hood already? This is better than a 1 line include how exactly? > Ah, the NPM/Composer golden brick road to development. Aka, the "I don't know what this is but I'm gonna lick it" approach to development I don't understand what you're saying here, everyone should be writing their own libraries from scratch? It has always been up to the developer to vet the dependencies they choose to include in their project. That applies to every language ecosystem, not just Node.
- stephenr 10y ago
  > According to the vast majority of authors of the most widely used and tested PHP libararies. So, FIG. "Group of developers say that groups' work is the best. News at 11." > You mean the autoloader builtins that composer uses under the hood already? No, spl_autoload is a working namespace aware autoloader. Composer uses a bunch of userland code. > I don't understand what you're saying here, everyone should be writing their own libraries from scratch? Did I say that? I've seen, multiple times the negative consequences of the current fad to rely on 25 separate, single-purpose 3rd party Libs, all of which are basic functionality that a well thought out library would give you, but with the added "bonus" of each relying on 20 other libraries to do basic things. > It has always been up to the developer to vet the dependencies they choose to include in their project. That applies to every language ecosystem, not just Node. Do the vast majority of developers know that? Because the ones I've had the "pleasure" of working with, definitely don't.