References between nested objects (PHP4)

[Markus Ernst]

Hello

In a content administration tool I call classes from inside classes in order
to separate the admin functions from the display-only functions:

class book
{
var $title;
var $author;
var $adminfunctions ;

function book($admin = false)
{
if ($admin) {
$this->adminfunctio ns =& new book_admin($thi s);
}
}

function display_book()
{
return $this->author.": ".$this->title;
}
}

class book_admin
{
var $boss;

function book_admin(&$bo ss)
{
$this->boss = $boss;
}

function update_book($au thor, $title)
{
$this->boss->author = $author;
$this->boss->title = $title;
}

[lots of other methods]
}

The admin code will be something like:

$book =& new book(true);
$book->adminfunctio ns->update_book("M ichael Crichton", "Jurassic Parc");
echo $book->display_book() ;

As you see there is a circle reference, as book_admin::bos s is a reference
back to book. I assume this is bad, and actually there are some problems
that I suspect are originated there.

Is there another possibility to access properties of the calling object? I
did not find any syntax similar to the parent::propert y syntax, and I can't
use inheritance, as there is already a vertical inheritance (such as page
extends book extends library...), and it is not possible to inherit two
classes.

Thanks for a hint!
Markus

[Chung Leong]

Reference is kinda kooky in PHP 4. I always try to dissuade people from
using it.

In the book_admin constructor, you need $this->boss =& $boss.
Otherwise the object will end up with a copy of its container.

[Hilarion]

> In a content administration tool I call classes from inside classes in order

to separate the admin functions from the display-only functions:

class book
{
var $title;
var $author;
var $adminfunctions ;

function book($admin = false)
{
if ($admin) {
$this->adminfunctio ns =& new book_admin($thi s);
}
}

function display_book()
{
return $this->author.": ".$this->title;
}
}

class book_admin
{
var $boss;

function book_admin(&$bo ss)
{
$this->boss = $boss;
As Chung Leong pointed out you should probably change the line
above to

$this->boss =& $boss;

}

function update_book($au thor, $title)
{
$this->boss->author = $author;
$this->boss->title = $title;
}

[lots of other methods]
}

The admin code will be something like:

$book =& new book(true);
$book->adminfunctio ns->update_book("M ichael Crichton", "Jurassic Parc");
echo $book->display_book() ;

As you see there is a circle reference, as book_admin::bos s is a reference
back to book. I assume this is bad, and actually there are some problems
that I suspect are originated there.
Circular references are not something bad in general. Reference to "parent"
in a "child" and to "children" from "parent" are usually ok.

Is there another possibility to access properties of the calling object? I
did not find any syntax similar to the parent::propert y syntax, and I can't
use inheritance, as there is already a vertical inheritance (such as page
extends book extends library...), and it is not possible to inherit two
classes.

You are using some strange inheritance (as you described it, but it's not
in your example code). Book should not extend page, page should not extend
book. Book should contain pages (have references to them), page should (or
could) have reference to the book. Same with library and books. In your
scenario each page can be treated as a book or a library and each book can
be treated as a library. You should probably also not use inheritance
between book and book admin.
Hilarion

[Markus Ernst]

Chung Leong wrote:

Reference is kinda kooky in PHP 4. I always try to dissuade people
from using it.

In the book_admin constructor, you need $this->boss =& $boss.
Otherwise the object will end up with a copy of its container.

Thank you very much for this comment - this does indeed solve the problems I
had!

Anyway my goal is improving performance at the front end (implementing PEAR
Cache did a lot there), and I am not sure if separating the admin functions
is actually worth the effort. I would highly appreciate some quick comments
about this:

Existing structure: Class trees based on common base classes, such as:

- class common_function s
- class entity extends common_function s

- class rubric extends entity
- class page extends rubric

- class gallery extends entity

- class picture extends entity

Class common_function s contains some methods used for display and lots of
methods used for administration (such as string formatting, outputting form
fields and other stuff), and also integrates the database, language and
configuration objects.
Class entity controls the dependencies between it's sub-objects.
Class entity and it's subclasses all have 1 method for retrieving data and 3
methods for administration (create/update, duplicate, delete).

Thus, also for the front-end scripts all the administration methods are
loaded. So I thought of 2 possible levels of separation:

1. The admin methods are separated only from class common_function s and
integrated as a separate object. The $boss reference can be avoided there,
as those methods do either directly address the database or return values
instead of setting class properties. But the admin methods of the
sub-objects will still be loaded by the front-end scripts.

2. The admin methods are separated from all classes and build a separate
class tree:
- class entity_admin extends common_function s_admin
- class rubric extends entity_admin
and so on; the the main tree subclass constructor tells it's parents which
admin class has to be loaded.

I implemented solution 2 now and compared the execution times of the most
time-consuming front-end page (a gallery overview, creates 1 entity, rubric,
page and gallery object and 28 picture objects for the thumbnails). There is
no significant difference; it takes between 2.0 and 2.3 seconds[1] (without
caching of course). On the other side, the admin scripts run slower.

[1] Yes, I have some more ideas where to reduce server load...

So what I would like to know is: Does it make a significant difference if
only about 200 lines of code are loaded instead of about 1000 lines? Or is a
possible performance gain compensated by the more complex structure?
Now this has got a lot of text - if somebody takes his/her time to give me a
comment about it: Thanks a lot in advance!
Markus

[Markus Ernst]

Hilarion wrote:

As you see there is a circle reference, as book_admin::bos s is a
reference back to book. I assume this is bad, and actually there are
some problems that I suspect are originated there.

Circular references are not something bad in general. Reference to
"parent" in a "child" and to "children" from "parent" are usually ok.

Thank you, I am happy to read this!

Is there another possibility to access properties of the calling
object? I did not find any syntax similar to the parent::propert y
syntax, and I can't use inheritance, as there is already a vertical
inheritance (such as page extends book extends library...), and it
is not possible to inherit two classes.

You are using some strange inheritance (as you described it, but it's
not in your example code). Book should not extend page, page should
not extend book. Book should contain pages (have references to them),
page should (or could) have reference to the book. Same with library
and books. In your scenario each page can be treated as a book or a
library and each book can be treated as a library. You should
probably also not use inheritance between book and book admin.

Yes I am sorry the example code was a poor example; I was quite tired and
annoyed when I wrote it. The classes actually behave the way you say they
should:

- common_function s
- entity extends common_function s
- "thing" extends entity

"Thing" will be the class to be actually instanciated, while some "things"
can have subclasses (as page extends rubric, because a page needs all the
properties and methods that a rubric has), and the relations between the
objects are handled at entity level via parent and order properties - thus
theoretically every kind of "thing" could be assigned to every other.

Thank you for your clarifications.

Markus

[Hilarion]

> Yes I am sorry the example code was a poor example; I was quite tired and

annoyed when I wrote it. The classes actually behave the way you say they
should:

- common_function s
- entity extends common_function s
- "thing" extends entity

"Thing" will be the class to be actually instanciated, while some "things"
can have subclasses (as page extends rubric, because a page needs all the
properties and methods that a rubric has),
Consider using common base class (eg. "document_fragm ent") for "rubric"
and "page" instead of inheritance between those.

and the relations between the
objects are handled at entity level via parent and order properties - thus
theoretically every kind of "thing" could be assigned to every other.

You should be more type-safe. I mean if the reference is always to an object
of specific class and is mostly used as the class, then you should make
sure, that it's always referred to as this class, not some base class.
Eg. you should use type hinting in PHP 5 and "instanceof " operator (in PHP 5)
or "is_a" function (in PHP 4 or 5).
Hilarion

[Chung Leong]

Markus Ernst wrote:

Anyway my goal is improving performance at the front end (implementing PEAR
Cache did a lot there), and I am not sure if separating the admin functions
is actually worth the effort. I would highly appreciate some quick comments
about this:

Existing structure: Class trees based on common base classes, such as:

- class common_function s
- class entity extends common_function s

- class rubric extends entity
- class page extends rubric

- class gallery extends entity

- class picture extends entity

I'm an advocate for keeping things simple and obvious. Unless there's a
good reason to use inheritance, I generally avoid it. It's easier to
think that a book is a book, than a book being an extension of some
generalized, abstract object.

[Markus Ernst]

Chung Leong wrote:

I'm an advocate for keeping things simple and obvious. Unless there's
a good reason to use inheritance, I generally avoid it. It's easier to
think that a book is a book, than a book being an extension of some
generalized, abstract object.

Yes, this is a very useful guideline one sometimes tends to forget. Anyway
in this case the generalized abstract object is useful for handling the
relations between different things - i.e. a text element can be assigned to
a page, or to an author (biography), or to a book (abstract). A page can be
assigned to a rubric, or to an author (extended biography, works list...),
or to a book (review, excerpt...). Therefore I decided to use one
centralized ID and relations handling.

[Markus Ernst]

Hilarion wrote:

You should be more type-safe. I mean if the reference is always to an
object of specific class and is mostly used as the class, then you
should make sure, that it's always referred to as this class, not
some base class. Eg. you should use type hinting in PHP 5 and "instanceof "
operator
(in PHP 5) or "is_a" function (in PHP 4 or 5).

I see I got myself into some complicated things here and will have to spend
some more time with the manual :-)

[Jerry Stuckle]

Markus Ernst wrote:

Yes, this is a very useful guideline one sometimes tends to forget. Anyway
in this case the generalized abstract object is useful for handling the
relations between different things - i.e. a text element can be assigned to
a page, or to an author (biography), or to a book (abstract). A page can be
assigned to a rubric, or to an author (extended biography, works list...),
or to a book (review, excerpt...). Therefore I decided to use one
centralized ID and relations handling.

Markus,

But herein lies the problem. Inheritance is not applicable here. A
text element is not a "type of" a page. Rather, a page "contains" one
or more text elements.

A biography is a "type of" a book, so it would be applicable to derive
biography from book. The book also "has an" author, but the author is
not a "type of" text element (or vice versa).

Applying inheritance correctly can be quite complex - and I've seen it
misused quite a bit.

I use inheritance a fair amount. For instance - one I'm working on now
is for a non-profit. I have a hierarchy:

Person -> Member -> Board Member

Person includes non-members who have attended meetings and otherwise
shown an interest in the organization. Members are Persons with a
Member ID number and an expiration date. Board Member has the
additional attribute of Position.

Unfortunately, MySQL isn't an OO DB, so I need to fudge a little. I
could, for instance, put a Position column in the Persons table. But
that would end wasting space for those who are non-members.

So, I assign every person an internal ID (auto increment column). I
have a Members table with the ID, membership number which is linked to
the Person table. And a BoardMember table contains the ID and position.

The beauty of this is that all the work is hidden. If, for instance, I
want to send an email to everyone, I use a PersonList object. For
Members, a MemberList object, and Board Members I create a
BoardMemberList object. *All* the rest of the code to send the emails
is exactly the same. It's just a matter of which object I create. In
fact, the creation of the object is similar to:

switch($POST['mailto']) {
case 'All' :
$list=new PersonList();
break;
case 'Members':
$list = new MemberList();
break;
case 'Board':
$list = new BoardMemberList ();
break;
default:
$emsg = 'No list selected';
break;
}
(rest of processing)

This is a perfect *applicable* use for inheritance.
--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attgl obal.net
=============== ===