Re: Using a Resource as a Class Property

Jerry Stuckle wrote:
Sanders Kaufman wrote:

So, by having the child modify the parent connection parameters, it can talk to whoever it needs to... not just my primary.

There are two ways to look at this. The more portable way would be to have a class which just connects to a database but doesn't actually define the database. Then you could have a derived class "DefaultDatabase" which connects to your default.

Yeah, I started to go there - but that would have been one level of complexity, too far for this architecture... or architect, anyway. Better to just set a few properties and say "connect()".

Another way would be to have the database name as the default parameter to the constructor for the Database class.

I'm not using parameters in my constructor.
I wasn't sure if I could have constructor parms at all when I started this thing.

Also, the idea of doing this:
"$x = new MyObject($y, $z)"
instead of this:
"$x = new MyObject()"
just *feels* wrong to me.

I'm not sure why - but it's probably legacy cringing from some other platform and package in my past.

It's ALL good - although every answer seems to beg another question!
In this case - abstract methods?
Is this another OOP thing that PHP4 doesn't do?

Yes, abstract methods are a PHP 5 implementation (and in most other OO languages). It means the base class has defined but not implemented the method. This makes the base class an "abstract class", and you won't be able to instantiate an object of that class.

Ooooh. That seems significant to my design - at least, for the next iteration in PHP5, anyway.
My baseclass is not designed to be instantiated, and it kinda irked me that it could be. I even added a bit of PHPDoc to warn the developer not to try. But that's a lousy way to code!

Abstract classes are used for inheritance. A derived class must implement all of the abstract methods in the base class (or it, too, will be an abstract class). An abstract class with only abstract methods would be an "interface", as Toby mentioned in another post.

Saturation level reached.
Information overload in effect.
Commence spinning of room.
Let's continue THAT part of the conversation in a few months, eh?

Fortunately, I didn't fall into that trap.
In fact, in designing my project, I (wrongly) presumed that I could not overrride functions in PHP.

You can override functions in PHP; it's very commonly done when the derived class needs to do some work, also. But the derived class should also be calling the function in the base class so the base class can perform its work.

This looks like something I'm going to have to HEAVILY consider in the next iteration of the code - abstract classes, interfaces and function overrides.