I’ll try and define some of those terms as I understand them.
a class that cannot be instantiated directly but only once subclassed with all the necessary parts of its implementation (abstract methods) supplied.
In Ruby and some other languages these are called mixins. They are basically collections of methods that can be included, so to speak, into a class. A class can include more than one mixin which is a pretty big deal
bounding box for declarations of all kinds. Before namespaces in PHP everything declaration could be thought of as existing in a single, global, namespace. The ability to name and create namespaces explicitly allows declarations to be divided up greatly reducing the chance of name collisions. Multiple namespaces can be imported into any one scope
a set of method signatures that act as a type for purpose of type-checking. Any class that implements those methods can declare itself as such and instances of that class will then type check as instances of the interface. Interestingly Golang doesn’t have the requirement of a class having to explicitly state it implements a particular interface; the compiler just checks if the required methods are there and if they are then the instance will pass as a instance of that interface.[/indent]
My language is PHP, but I know it is not an OOP-first language.
No PHP isn't purely object-oriented but the distinction really isn’t very important from your standpoint. PHP has a butt-load of OOP features. You can do OOP in PHP just fine. That’s all that matters.
I am trying to understand OOP better, and much of the theoretical material is written for other languages. I am having trouble understanding OOP design materials I occasionally come across. So that's why I am (still) interested in this.
Can you post an example of a specific thing you are having difficulty understanding? Perhaps we could help you with that.
Honestly, why not learn Java while learning OOP principle? I understand you may or may ever use Java but I really think it's a MUST skill to have as it's #1 demanded IT technology in current job market.
You can get jobs doing functional programming or UI stuff without any experience with OO so I don't think you can really call it a must skill. But then I suppose programming as a whole isn't a must skill either so it really depends what you want to do. There are enough jobs in programming that you do have some choice where you want to put your focus. If you like to be safe and go with what is popular than, yes, learning OOP, and probably Java, is a very good idea indeed. Personally speaking, I’m quite happy to deviate from convention but nevertheless spent a long time trying to figure out how to do OOP robustly on the basis of what it was supposed to do. I ended up concluding that it doesn’t live up to its claims and its limitations cannot be easily surpassed without starting to do something resembling some other kind of programming, at which point you might as well just do that other kind of programming.