Where to put plain object classes?

@includebeer

Something is wrong with me, require_once is OK. I am lazy.
Off-topic: Future without $this->load->this() and $this->load->that() would be perfect for me. :-)

But when the target class is static... What then?

What's wrong with require_once ?
We don't need to reinvent the wheel just because we use a framework.

Unfortunately, require_once doesn't take in account CodeIgniter Packages.

https://ellislab.com/codeigniter/user-gu...oader.html

https://github.com/ProjectOrangeBox / https://github.com/dmyers2004

Unfortunately, require_once doesn't take in account CodeIgniter Packages.

https://ellislab.com/codeigniter/user-gu...oader.html

The original question was about a simple class...???

Yet another example about autoloading classes by using a hook, this time for supporting base controllers:
http://avenir.ro/codeigniter-tutorials/n...ontroller/

Rufnex is correct, just as a side note thou:
You would of course use $this->load->library('PlainObject'); to load this class and of course this would automatically attach it to the CI super object as a singleton. $this->plainobject->method(); etc...

If you need to create multiple "plain objects". You can then always $foo = new plainobject(); after calling $this->load->library('PlainObject');
because of course $this->load->library('PlainObject'); already loaded the class.
You of course have the singleton still attached to the super object thou.

Am I to understand that simply loading a class definition results in a controller attempting to instantiate the object? That seems strange to me. What if the object requires arguments to a constructor? What if you don't want a property attached to the controller? Also, what if the object is in fact an abstraction that serves as an ActiveRecord interface for a database? Might such classes belong in the model directory?

Rufnex is correct, just as a side note thou:
You would of course use $this->load->library('PlainObject'); to load this class and of course this would automatically attach it to the CI super object as a singleton. $this->plainobject->method(); etc...

If you need to create multiple "plain objects". You can then always $foo = new plainobject(); after calling $this->load->library('PlainObject');
because of course $this->load->library('PlainObject'); already loaded the class.
You of course have the singleton still attached to the super object thou.

Am I to understand that simply loading a class definition results in a controller attempting to instantiate the object? That seems strange to me. What if the object requires arguments to a constructor? What if you don't want a property attached to the controller? Also, what if the object is in fact an abstraction that serves as an ActiveRecord interface for a database? Might such classes belong in the model directory?

There is no an "official" way of doing that. The manual loader comes from PHP4 times and it stays as it is.

You have two options for using framework-agnostic classes:

1. To make a custom autoloader. I proposed (and I recommend) it to be activated by using a hook, because it seems to me less "hackish" way. In my developments I modify the core files anyway for various reasons, this is why I include the autoloader at some point of bootstrapping. Yes, autoloading models is nice, because I can extend them without the need for include/require. See a sample rich implementation: https://github.com/ivantcholakov/starter...toload.php

I prefer this option just to put my stuff and to use it without any bureaucracy.

2. The second option is Composer. I prefer it only for ready yet external components. During my work I don't want to write packages of my own (and to upload them to Packagist? - no way, no time for that). I just want to get the job done.

Using Composer is the way to go. But you don't have to setup a package with packagist or any of that stuff. Just use if for it's autoloader.

You can make a new folder anywhere you want. Call it "mystuff". Now, create a composer.json file with the following contents:

Code:

{
   "autoload": {
       "psr-4": {
           "MyStuff\\": "mystuff/"
       }
   }
}

Then you can create classes with the MyStuff namespace and have Composer provide the autoloading.

Support Development •  CodeIgniter 4 Foundations • Practical CodeIgniter 3  • CodeIgniter Tutorials

easiest way:

put it into the application/libraries folder
autoload this library in your application/config/autoload.php

then from anywhere in your controllers/models user: $this->library_name_here->some_function();

from other libraries in application/libraries or from helper files: $ci = get_instance(); $ci->library_name_here->some_function();

"I reject your reality and substitute my own" - Adam Savage, M5 Inc.

easiest way:

put it into the application/libraries folder
autoload this library in your application/config/autoload.php

then from anywhere in your controllers/models user: $this->library_name_here->some_function();

from other libraries in application/libraries or from helper files: $ci = get_instance(); $ci->library_name_here->some_function();

I really must contest that this is the 'easiest' way. This approach seems totally silly to me for the reasons I pointed out above:
* What if a class is only to be used statically. I.e., you NEVER instantiate this class for any reason because all of its methods are static.
* What if you must supply arguments to the constructor for the class? This would in all likelihood cause a fatal error if CodeIgniter tried to instantiate the object without providing these parameters.
* What if I need multiple instances of MyClass to perform some operation. E.g.:

Code:

$player1 = new Player("Mutt", $foo);
$player2 = new Player("Jeff, $bar);

In that case, why on earth would I tolerate the overhead of CI trying to instantiate the object??

ivantcholakov seems to have the most helpful suggestions in this matter. I agree that an autoloader is extremely useful for eliminating thickets of require/include statements. It's been my experience that these include/require statements are the source of much code redundancy and many bugs.

As for using Composer, I am not familiar with it, but that seems to me to introduce a completely unnecessary dependency and additionally requires one to maintain composer.json as well each time one adds additional classes or libraries. Perhaps I'm missing something.

* What if a class is only to be used statically. I.e., you NEVER instantiate this class for any reason because all of its methods are static.

It's been my experience that these include/require statements are the source of much code redundancy and many bugs.

Code redundancy and bugs? It's only one line of code. I can live with one redundant line!
I'm curious what kind of bugs you had with include/require you don't have with an autoloader.

* What if you must supply arguments to the constructor for the class? This would in all likelihood cause a fatal error if CodeIgniter tried to instantiate the object without providing these parameters.

You can pass arguments to the loader class in the second parameter:

$params (array) – Optional array of parameters to pass to the loaded library’s constructor

http://www.codeigniter.com/userguide3/li...-reference

* What if I need multiple instances of MyClass to perform some operation.

Then use require_once!

Maybe I'm too old school, but I don't understand why people have trouble doing simple things just because they use a framework. What would you do in plain PHP? If CI doesn't provide what you're trying to do then do it in plain PHP.