Using a Resource as a Class Property

[Sanders Kaufman]

I'm wondering if I'm doing this right, as far as using another class
object as a PHP class property.

class my_baseclass {
var $Database;
var $ErrorMessage;
var $TableName;
var $RecordSet;
function my_baseclass(){
$this->TableName = "";
$this->RecordSet = array();
$this->Database = new my_database();
$this->ErrorMessage = $this->Database->ErrorMessage;
return true;
}
}

It seems to be working, but this kinds stuff skirts the edge of my PHP
grok, so I dunno.

[Jerry Stuckle]

Sanders Kaufman wrote:

Jerry Stuckle wrote:

>You can't change the base class method - by definition, it's part of
the interface. But the variable is part of the implementation. In a
proper design you can change the variable (and, of course, the BODY of
functions which reference it) without changing the interface - and the
child classes.

Speaking of named methods and overrides...
I just now realized that I had a TableName property in both my baseclass
and my extended class... accidentally overriding, right?

But... can I still have it in both places, calling the baseclass
property with one of those :: operators?

Or does the overriding kill that altogether?

No, overriding doesn't kill this. However, generally you would want to
call the derived class's function, and that one would call the base
class's function.

If the functions have the same name, the child class's function should
be an extension of the base class's function. If the child class
function is not, it should have a different name.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Jerry Stuckle]

Sanders Kaufman wrote:

Jerry Stuckle wrote:

>Sanders Kaufman wrote:

>>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.

Not at all. The whole purpose of the constructor is to initialize the
object. It is probably more common to pass parameters to the object's
constructor than not.

For instance, the constructor for the mysqli class:

mysqli mysqli_connect ( [string host [, string username [, string
passwd [, string dbname [, int port [, string socket]]]]]] )

If you pass a host, it will try to connect to the host. If you pass a
username, it will connect using that username. If password is
specified, it will also use that password, etc.

If no parameters are specified, then no connection is attempted.

Yeah - I'm totally cool with the fact that some folks use parms in the
construction, and on a thinky level, I can certainly see where it would
be handy. But it really feels wrong.

I have the same issue with using voids... although I use 'em, it just
feels like the same kind of wrong.

Actually, it's not that much different than defining a variable and
providing it a value, i.e.

$i = 3;

Of course there isn't any way to define a simple variable in an untyped
language like PHP, but it's still considered good form in typed languages.

About the closes you could come in PHP is defining and initializing an
array, i.e.

$i = array('zero', 'one', 'two');

Not always done, but you get the idea.

>

>>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.

Yep.

I'd also recommend you pick up a decent book on OO in general. It
will explain things a lot better than we can here in the newsgroup.

I'm not very good about learning from tutorial books. I get all the way
through, don't miss a thing, do all of the exercises... and then have no
idea what I learned.

If I'm gonna learn this stuff, it's gonna be because someone taught it
to me here and in the OOP groups. I'll probably also draw up a nice
poster to remind me about Inheritance, Polymorphism, Abstraction and
Encapsulation.

You still need to look at the books. Sure, you'll have questions. But
a good book will also answer a lot of questions you might have.

And as I said - it's impossible to get into the amount of detail here in
a newsgroup that you can get from a book.

I teach an OO course. It's five days of intensive learning. OO books
are 200-300 pages or more. There's no way we can handle that type of
detail in a newsgroup.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Sanders Kaufman]

Jerry Stuckle wrote:

Sanders Kaufman wrote:

>I just now realized that I had a TableName property in both my
baseclass and my extended class... accidentally overriding, right?

But... can I still have it in both places, calling the baseclass
property with one of those :: operators?

Or does the overriding kill that altogether?

No, overriding doesn't kill this. However, generally you would want to
call the derived class's function, and that one would call the base
class's function.

If the functions have the same name, the child class's function should
be an extension of the base class's function. If the child class
function is not, it should have a different name.

So when I override a function, it actually calls the baseclass function
AND THEN the derived function? Did I understand that right?

[Sanders Kaufman]

Jerry Stuckle wrote:

Sanders Kaufman wrote:

>Yeah - I'm totally cool with the fact that some folks use parms in the
construction, and on a thinky level, I can certainly see where it
would be handy. But it really feels wrong.

I have the same issue with using voids... although I use 'em, it just
feels like the same kind of wrong.

Actually, it's not that much different than defining a variable and
providing it a value, i.e.

$i = 3;

Good point.

I teach an OO course. It's five days of intensive learning. OO books
are 200-300 pages or more. There's no way we can handle that type of
detail in a newsgroup.

Classes rock.

[Jerry Stuckle]

Sanders Kaufman wrote:

Jerry Stuckle wrote:

>Sanders Kaufman wrote:

>>I just now realized that I had a TableName property in both my
baseclass and my extended class... accidentally overriding, right?

But... can I still have it in both places, calling the baseclass
property with one of those :: operators?

Or does the overriding kill that altogether?

No, overriding doesn't kill this. However, generally you would want
to call the derived class's function, and that one would call the base
class's function.

If the functions have the same name, the child class's function should
be an extension of the base class's function. If the child class
function is not, it should have a different name.

So when I override a function, it actually calls the baseclass function
AND THEN the derived function? Did I understand that right?

No, it doesn't. It only calls the derived class function. But the
derived class function should call the base class function.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Jerry Stuckle]

Sanders Kaufman wrote:

Jerry Stuckle wrote:

>Sanders Kaufman wrote:

>>Yeah - I'm totally cool with the fact that some folks use parms in
the construction, and on a thinky level, I can certainly see where it
would be handy. But it really feels wrong.

I have the same issue with using voids... although I use 'em, it just
feels like the same kind of wrong.

Actually, it's not that much different than defining a variable and
providing it a value, i.e.

$i = 3;

Good point.

>I teach an OO course. It's five days of intensive learning. OO books
are 200-300 pages or more. There's no way we can handle that type of
detail in a newsgroup.

Classes rock.

Yes, my customers (all corporate) think so. But they're not cheap,
either :-)

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Sanders Kaufman]

Jerry Stuckle wrote:

Sanders Kaufman wrote:

>So when I override a function, it actually calls the baseclass
function AND THEN the derived function? Did I understand that right?

No, it doesn't. It only calls the derived class function. But the
derived class function should call the base class function.

Oh, OK. I misunderstood "should".
You're saying that if I override a function, I should be calling the
overridden function from within the override at some point.
This is an OOP design principle, but not necessarily enforced in the
compiler/IDE thingies.
It's that way because, there's not much point in writing a function that
just gets voided in the actual implementation and because it allows you
to put some shared or common functionality deeper down (higher up?) into
the foundation of the architecture.

Zat right?

[Sanders Kaufman]

Jerry Stuckle wrote:

Sanders Kaufman wrote:

>Jerry Stuckle wrote:

>>I teach an OO course. It's five days of intensive learning. OO
books are 200-300 pages or more. There's no way we can handle that
type of detail in a newsgroup.

Classes rock.

Yes, my customers (all corporate) think so. But they're not cheap,
either :-)

What a great racket.
I got a friend does that with OSHA training.
She makes WAAAAY too much money teaching cubicle rats how to use
automagic defibrilators.

[Toby A Inkster]

Sanders Kaufman wrote:

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!

In PHP5 you can mark this as an abstract class. The interpreter prevents
anyone from instantiating an abstract class.

--
Toby A Inkster BSc (Hons) ARCS
[Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux]
[OS: Linux 2.6.12-12mdksmp, up 33 days, 12:18.]

Parsing an HTML Table with PEAR's XML_HTTPSax3
http://tobyinkster.co.uk/blog/2007/0...table-parsing/

[Jerry Stuckle]

Sanders Kaufman wrote:

Jerry Stuckle wrote:

>Sanders Kaufman wrote:

>>So when I override a function, it actually calls the baseclass
function AND THEN the derived function? Did I understand that right?

No, it doesn't. It only calls the derived class function. But the
derived class function should call the base class function.

Oh, OK. I misunderstood "should".
You're saying that if I override a function, I should be calling the
overridden function from within the override at some point.
This is an OOP design principle, but not necessarily enforced in the
compiler/IDE thingies.
It's that way because, there's not much point in writing a function that
just gets voided in the actual implementation and because it allows you
to put some shared or common functionality deeper down (higher up?) into
the foundation of the architecture.

Zat right?

That is true. The problem is - if you don't call the base class
function, work the base class needs to do for other things may not be
performed. For instance, a variable in the base class may not be set,
and that variable may be used in a subsequent call to a base class function.

No, compilers don't enforce it. But it's a good idea.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Jerry Stuckle]

Sanders Kaufman wrote:

Jerry Stuckle wrote:

>Sanders Kaufman wrote:

>>Jerry Stuckle wrote:

>>>I teach an OO course. It's five days of intensive learning. OO
books are 200-300 pages or more. There's no way we can handle that
type of detail in a newsgroup.

Classes rock.

Yes, my customers (all corporate) think so. But they're not cheap,
either :-)

What a great racket.
I got a friend does that with OSHA training.
She makes WAAAAY too much money teaching cubicle rats how to use
automagic defibrilators.

You'd be surprised. It's not all that great money, and it's a lot of
hard work. You wouldn't believe what I have to pay for an instructor
(no, I don't do all the classes myself).

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Sanders Kaufman]

Jerry Stuckle wrote:

Sanders Kaufman wrote:

>I got a friend does that with OSHA training.
She makes WAAAAY too much money teaching cubicle rats how to use
automagic defibrilators.

You'd be surprised. It's not all that great money, and it's a lot of
hard work. You wouldn't believe what I have to pay for an instructor
(no, I don't do all the classes myself).

Yeah - it's hard work. I think the hardest part is that it's as much
about being sociable as it is about being an expert in the subject.

Me - I couldn't sell a pardon to a prisoner.