User Guide: Libraries vs Core Classes

[eluser]oribani[/eluser]
I'm reading through the user guide and so far, it's nicely written, easy to follow. I do wish it continued with what is basically an embedded "blog" tutorial, but it leaves off after just helping you create a view page. If it kept going that'd be nice, but I expect to find a tutorial elsewhere that will probably fill in the gap.

The main problem I have with the user guide so far is nomenclature. I wish "helper" would just be called what it really is: "library". Of course, there is this other artificial categorization of classes that are referred to as the "library", but that's non-sensical: why do classes have to be the library and procedural functions have to be helpers? Plugins too - they are the same (from what I can tell) as helpers. I find all this artificial, non-standard nomenclature to be unhelpful.

The point of the title of this post was to ask what the difference is between the user guide pages on creating/extending libraries and core classes.

http://ellislab.com/codeigniter/user-gui...aries.html
http://ellislab.com/codeigniter/user-gui...asses.html

The two pages have mostly the same information on them (unless I missed something) and moreover they seem to tell you how to override classes that are in the same directory. Did I miss something or is the only difference that "core classes" are those that are auto-loaded by CI? I don't see the need for two pages in the user guide about this - I think it only confuses the reader.

[eluser]jedd[/eluser]
Hi oribani and welcome to the CI forums.

[quote author="oribani" date="1252641719"]
The two pages have mostly the same information on them (unless I missed something) and moreover they seem to tell you how to override classes that are in the same directory. Did I miss something or is the only difference that "core classes" are those that are auto-loaded by CI?
[/quote]

s/auto-loaded by/shipped with/

Or, if you prefer a less succinct way of describing that distinction -- core classes are those shipped by CI, and you can extend them if you want (this is in preference to copying them and modifying them to taste).

Keep in mind that some of the distinctions or separations here are to make the process of upgrading easier. Oh, and yes, a little duplicated information there - but that's better than contradictory advice, no?

[eluser]oribani[/eluser]
Thanks for your reply. It's not that I misunderstand that the first page tells you how to create your own "library"... my problem/confusion starts half way down the page where you find two sections:

http://ellislab.com/codeigniter/user-gui...aries.html
Replacing Native Libraries with Your Versions
Extending Native Libraries

Those tell me the same thing as is on the following page

http://ellislab.com/codeigniter/user-gui...asses.html

What did I miss or should those two pages be merged or clarified?

[eluser]brianw1975[/eluser]
I just want to point out that the majority of the MY_files (MY_Controller, MY_Model, etc) typically go in system/application/libraries where as the core files go in system/libraries/ so those files aren't really overriding files that are already in the same directory -- maybe this will help clear some things up?

[eluser]jedd[/eluser]
You're right - they could do with some clean-up.

Derek has [url="http://ellislab.com/forums/viewthread/128680/"]suggested he's be happy to take some properly marked up changes[/url] if you feel up to the task?

I suspect that we're all a bit immune to noticing the quirks and redundancies in the manual. Like how you get used to an orange-painted kitchen after 6 months, and don't understand why everyone hurls when they visit.

[eluser]oribani[/eluser]
[quote author="brianw1975" date="1252646247"]I just want to point out that the majority of the MY_files (MY_Controller, MY_Model, etc) typically go in system/application/libraries where as the core files go in system/libraries/ so those files aren't really overriding files that are already in the same directory -- maybe this will help clear some things up?[/quote]

Where you are supposed to put your extensions/replacements for "libraries" (which seems to be synonymous with "core classes") has nothing to do with the fact that these two pages tell you the same thing but use different nomenclature.

http://ellislab.com/codeigniter/user-gui...aries.html
Replacing Native Libraries with Your Versions
Extending Native Libraries

http://ellislab.com/codeigniter/user-gui...asses.html

By "same directories" I mean the user guide tells you that "libraries" and "core classes" are in the SAME place. That means they are using "libraries" and "core classes" to mean the same thing, which is the problem. If I missed something, someone please point it out.

So I think you missed the point and I still am not convinced that this isn't badly chosen nomenclature which lead to two confusing user guide pages.

[eluser]oribani[/eluser]
[quote author="jedd" date="1252646713"]You're right - they could do with some clean-up.

Derek has [url="http://ellislab.com/forums/viewthread/128680/"]suggested he's be happy to take some properly marked up changes[/url] if you feel up to the task?

I suspect that we're all a bit immune to noticing the quirks and redundancies in the manual. Like how you get used to an orange-painted kitchen after 6 months, and don't understand why everyone hurls when they visit.[/quote]

Ahh, yes. Open Source. :-) I could do it if I weren't saddled with a workload way above my head. :-(

Honestly, if I were to re-write it, I'd choose to do more than correct those two pages - as I mentioned, I think it's misleading to make artificial distinctions between "helpers", "libraries", "core classes", and "plugins" because there's not much difference between some of those, or the differences are too confusing and should be re-thought.

Sorry I can't offer concrete help at the time.

[eluser]BrianDHall[/eluser]
Actually, I don't know that I understand the real difference between a plugin and a library.

I think the idea of a helper is just that its suppose to be some useful functions that are useful everywhere - the reason for the destinction is that they are not object oriented. Once loaded they behave like a native PHP function, that is to say you can just call sha1() or md5() or trim() anywhere.

Libraries and plugins, to my understanding, are more object oriented and they are more tightly integrated and organized. For instance in file uploads $this->upload->data() is meaningless and useless unless you are using the other functions of the upload class, or the Session class - their functions only work if you use the whole library. Meanwhile the HTML helper function img() is just handy in all sorts of places.

Core classes mean they are available on all CI systems.

Plugins is what I flat don't know about - what's the difference in a plugin and a library?

The manual does need cleaned in this respect, but we must first know and agree what is correct before we can attempt to explain it to others.

EDIT:

On extending core classes, you are not 'supposed' to ever change a core class, because you become locked into those changes and cannot easily upgrade to newer versions of CI, and if you run into a problem it may be hard to get help from others because they have different code than you do.

Hm, is this the difference with what a plugin is? Is a plugin what you put in the same directory as the core classes that automatically over-ride the underlying classes automagically?

Then extending a core class is different because it is not automatic. You can make a MY_Controller class, but if you don't explicitly make a controller that extends "MY_Controller" instead of "Controller", then your special controller class doesn't get used.

Am I on the right track?

[eluser]jedd[/eluser]
[quote author="oribani" date="1252646838"]
If I missed something, someone please point it out.
[/quote]

I think you have.

Your own libraries AND your extensions to the core classes - live in the same directory. This doesn't mean that they are the exact same types of things.

I imagine your Open Source reference (I'm very much a free software vernacular kind of guy) was uttered in much the same tone that people usually reserve for complaining about how governments never do the right thing AND how they are asked, every four years, to allocate an hour or so of their time to do something vaguely democratic. Not really embracing the classic Greek tradition of being a good citizen, I've often thought.

But thanks for dropping in and spending a few moments to complain about the manual, in any case.

[eluser]oribani[/eluser]
[quote author="jedd" date="1252647934"][quote author="oribani" date="1252646838"]
If I missed something, someone please point it out.
[/quote]

I think you have.

Your own libraries AND your extensions to the core classes - live in the same directory. This doesn't mean that they are the exact same types of things.[/quote]

No, I don't think that's particularly relevant. First, it's *not* anything to do with your own custom libraries. And it's not a matter of where your extensions/replacements belong. The problem I am pointing out is that the "Replacing/Extending Native Libraries" section in the user guide seems to refer to the classes in system/libraries/. Then you go to the next user guide page and it's talking about these "core classes", but from what I can tell, that's the same thing in the same place: system/libraries/. Certainly the process for how to override these "core classes" is the same as how to override "native libraries". I still can't tell what the difference is.

[quote author="jedd" date="1252647934"]
I imagine your Open Source reference (I'm very much a free software vernacular kind of guy) was uttered in much the same tone that people usually reserve for complaining about how governments never do the right thing AND how they are asked, every four years, to allocate an hour or so of their time to do something vaguely democratic. Not really embracing the classic Greek tradition of being a good citizen, I've often thought.

But thanks for dropping in and spending a few moments to complain about the manual, in any case.[/quote]

No, that wasn't my meaning. I meant to acknowledge that it is indeed my responsibility as much as anyone else's to do something about it. My "sorry that I can't" was sincere.