Tweeted twitter.com/StackProgrammer/status/779754167518785536

occurred Sep 24, 2016 at 18:47

Post Reopened by Bart van Ingen Schenau, gnat, Wayne Molina, user53019, user28988

occurred Aug 18, 2014 at 22:32

deleted 38 characters in body

Source Link

edited Aug 18, 2014 at 22:29

user53019

Using the spl_autoload_register(), should I use a single autoload function that contains all the logic to determine where the include files are or should I break each include grouping into it's own function with it's own logic to include the files for the called function? As the places where include files may reside expands so too will the logic of a single function. If I break it into multiple functions I can add functions as new groupings are added, but the functions will be copy/pastes of each other with minor alterations.

Currently I have a tool with a single registered autoload function that picks apart the class name and tries to predict where it is and then includes it. Due to naming conventions for the project this has been pretty simple.

if has namespace 
  if in template namespace look in Root\Templates
  else look in Root\Modules\Namespace
else
  look in Root\System
if file exists include

But we are starting to include Interfaces and Traits into our codebase and it hurts me to include the type of a thing in it's name. So we are looking at instead of a single autoload function that digs through the class name and looks for the file and has increasingly complex logic to it, we are looking at having multiple autoload functions registered. But each one follows the same pattern and any time I see that I get paranoid about code copying.

function systemAutoloadFunc
  logic to create probable filename
  if filename exists in system include it and return true
  else return false

function moduleAutoloadFunc
  logic to create probable filename
  if filename exists in modules include it and return true
  else return false

Every autoload function will follow that pattern and the last of each function if filename exists, include return true else return false is going to be identical code. This makes me paranoid about having to update it later across the board if the file_exists include pattern we are using ever changes. Or is it just that, paranoia and the multiple functions with some identical code is the best option?

Also, we could use an autoload tag....

Using the spl_autoload_register(), should I use a single autoload function that contains all the logic to determine where the include files are or should I break each include grouping into it's own function with it's own logic to include the files for the called function? As the places where include files may reside expands so too will the logic of a single function. If I break it into multiple functions I can add functions as new groupings are added, but the functions will be copy/pastes of each other with minor alterations.

Currently I have a tool with a single registered autoload function that picks apart the class name and tries to predict where it is and then includes it. Due to naming conventions for the project this has been pretty simple.

if has namespace 
  if in template namespace look in Root\Templates
  else look in Root\Modules\Namespace
else
  look in Root\System
if file exists include

But we are starting to include Interfaces and Traits into our codebase and it hurts me to include the type of a thing in it's name. So we are looking at instead of a single autoload function that digs through the class name and looks for the file and has increasingly complex logic to it, we are looking at having multiple autoload functions registered. But each one follows the same pattern and any time I see that I get paranoid about code copying.

function systemAutoloadFunc
  logic to create probable filename
  if filename exists in system include it and return true
  else return false

function moduleAutoloadFunc
  logic to create probable filename
  if filename exists in modules include it and return true
  else return false

Every autoload function will follow that pattern and the last of each function if filename exists, include return true else return false is going to be identical code. This makes me paranoid about having to update it later across the board if the file_exists include pattern we are using ever changes. Or is it just that, paranoia and the multiple functions with some identical code is the best option?

Also, we could use an autoload tag....

Using the spl_autoload_register(), should I use a single autoload function that contains all the logic to determine where the include files are or should I break each include grouping into it's own function with it's own logic to include the files for the called function? As the places where include files may reside expands so too will the logic of a single function. If I break it into multiple functions I can add functions as new groupings are added, but the functions will be copy/pastes of each other with minor alterations.

Currently I have a tool with a single registered autoload function that picks apart the class name and tries to predict where it is and then includes it. Due to naming conventions for the project this has been pretty simple.

if has namespace 
  if in template namespace look in Root\Templates
  else look in Root\Modules\Namespace
else
  look in Root\System
if file exists include

But we are starting to include Interfaces and Traits into our codebase and it hurts me to include the type of a thing in it's name. So we are looking at instead of a single autoload function that digs through the class name and looks for the file and has increasingly complex logic to it, we are looking at having multiple autoload functions registered. But each one follows the same pattern and any time I see that I get paranoid about code copying.

function systemAutoloadFunc
  logic to create probable filename
  if filename exists in system include it and return true
  else return false

function moduleAutoloadFunc
  logic to create probable filename
  if filename exists in modules include it and return true
  else return false

Every autoload function will follow that pattern and the last of each function if filename exists, include return true else return false is going to be identical code. This makes me paranoid about having to update it later across the board if the file_exists include pattern we are using ever changes. Or is it just that, paranoia and the multiple functions with some identical code is the best option?

Added a tl;dr; to the beginning of the question that is the crux of my question.

Source Link

edited Aug 18, 2014 at 17:33

Tyson of the Northwest

193
1
7

Using the spl_autoload_register(), should I use a single autoload function that contains all the logic to determine where the include files are or should I break each include grouping into it's own function with it's own logic to include the files for the called function? As the places where include files may reside expands so too will the logic of a single function. If I break it into multiple functions I can add functions as new groupings are added, but the functions will be copy/pastes of each other with minor alterations.

Currently I have a tool with a single registered autoload function that picks apart the class name and tries to predict where it is and then includes it.

Due Due to naming conventions for the project this has been pretty simple.

if has namespace 
  if in template namespace look in Root\Templates
  else look in Root\Modules\Namespace
else
  look in Root\System
if file exists include

But we are starting to include Interfaces and Traits into our codebase and it hurts me to include the type of a thing in it's name. So we are looking at instead of a single autoload function that digs through the class name and looks for the file and has increasingly complex logic to it, we are looking at having multiple autoload functions registered. But each one follows the same pattern and any time I see that I get paranoid about code copying.

function autoloadfuncsystemAutoloadFunc
  logic to create probable filename
  if filename exists in system include it and return true
  else return false

function moduleAutoloadFunc
  logic to create probable filename
  if filename exists in modules include it and return true
  else return false

Every autoload function will follow that pattern and the last of each function if filename exists, include return true else return false is going to be identical code. This makes me paranoid about having to update it later across the board if the file_exists include pattern we are using ever changes. Or is it just that, paranoia and the multiple functions with some identical code is the best option?

Also, we could use an autoload tag....

Currently I have a tool with a single registered autoload function that picks apart the class name and tries to predict where it is and then includes it.

Due to naming conventions for the project this has been pretty simple.

if has namespace 
  if in template namespace look in Root\Templates
  else look in Root\Modules\Namespace
else
  look in Root\System
if file exists include

But we are starting to include Interfaces and Traits into our codebase and it hurts me to include the type of a thing in it's name. So we are looking at instead of a single autoload function that digs through the class name and looks for the file and has increasingly complex logic to it, we are looking at having multiple autoload functions registered. But each one follows the same pattern and any time I see that I get paranoid about code copying.

function autoloadfunc
  create probable filename
  if filename exists include it and return true
  else return false

Every autoload function will follow that pattern and the last of each function if filename exists, include return true else return false is going to be identical code. This makes me paranoid about having to update it later across the board if the file_exists include pattern we are using ever changes. Or is it just that, paranoia and the multiple functions with some identical code is the best option?

Also, we could use an autoload tag....

Using the spl_autoload_register(), should I use a single autoload function that contains all the logic to determine where the include files are or should I break each include grouping into it's own function with it's own logic to include the files for the called function? As the places where include files may reside expands so too will the logic of a single function. If I break it into multiple functions I can add functions as new groupings are added, but the functions will be copy/pastes of each other with minor alterations.

Currently I have a tool with a single registered autoload function that picks apart the class name and tries to predict where it is and then includes it. Due to naming conventions for the project this has been pretty simple.

if has namespace 
  if in template namespace look in Root\Templates
  else look in Root\Modules\Namespace
else
  look in Root\System
if file exists include

But we are starting to include Interfaces and Traits into our codebase and it hurts me to include the type of a thing in it's name. So we are looking at instead of a single autoload function that digs through the class name and looks for the file and has increasingly complex logic to it, we are looking at having multiple autoload functions registered. But each one follows the same pattern and any time I see that I get paranoid about code copying.

function systemAutoloadFunc
  logic to create probable filename
  if filename exists in system include it and return true
  else return false

function moduleAutoloadFunc
  logic to create probable filename
  if filename exists in modules include it and return true
  else return false

Every autoload function will follow that pattern and the last of each function if filename exists, include return true else return false is going to be identical code. This makes me paranoid about having to update it later across the board if the file_exists include pattern we are using ever changes. Or is it just that, paranoia and the multiple functions with some identical code is the best option?

Also, we could use an autoload tag....

Post Closed as "Needs details or clarity" by Wayne Molina, user40980, Bart van Ingen Schenau, gnat, jwenting

occurred Aug 18, 2014 at 9:50

Source Link

asked Aug 15, 2014 at 22:20

Tyson of the Northwest

193
1
7

Single complex or multiple simple autoload functions

Currently I have a tool with a single registered autoload function that picks apart the class name and tries to predict where it is and then includes it.

Due to naming conventions for the project this has been pretty simple.

if has namespace 
  if in template namespace look in Root\Templates
  else look in Root\Modules\Namespace
else
  look in Root\System
if file exists include

But we are starting to include Interfaces and Traits into our codebase and it hurts me to include the type of a thing in it's name. So we are looking at instead of a single autoload function that digs through the class name and looks for the file and has increasingly complex logic to it, we are looking at having multiple autoload functions registered. But each one follows the same pattern and any time I see that I get paranoid about code copying.

function autoloadfunc
  create probable filename
  if filename exists include it and return true
  else return false

Every autoload function will follow that pattern and the last of each function if filename exists, include return true else return false is going to be identical code. This makes me paranoid about having to update it later across the board if the file_exists include pattern we are using ever changes. Or is it just that, paranoia and the multiple functions with some identical code is the best option?

Also, we could use an autoload tag....

php include

Stack Exchange Network

Return to Question

Single complex or multiple simple autoload functions