I am currently rewriting a corporate CMS that was originally hacked
together in a hurry by a mamber of staff who is now leaving and which
is totally uncommented and is therefore in a state where maintaining
it would be a total nightmare. I'm redesigning it to take an OO
approach, but am limited to PHP 4 on the server on which it will run
and am therefore limited to that version's OO model.

The current plan is to have a hierarchy of classes going from the
general to the specific and inherit and override/extend functions as
necessary to achieve the desired results. At the top of the chain is
a CMS item object that defines props and methods that are common to
all items that will be stored by the CMS: Creation/last modified
dates, summaries, filesystem paths etc. From that I dreive classes
for specific types of CMS data. Documents, images and directories all
decend directly from the CMS item class.

As I was designing I originally intended for there to be a site class
that inherited from the item class, but as the design progressed I
realised that a site is basically a special case of a directory and
therefore should be derived from the directory class.

But here I hit a snag, because I need to access a method in the item
class while bypassing the same method in the directory class. In the
item class is a method that inserts some data into the items table of
the database. In the directory class this method is extended by
another method of the same name. This method runs the method in the
parent class with parent::method(), then does the extra SQL queries
that it needs to do for creating a directory.

The site class, however, uses a different pair of tables (item and
site) to the directory class (item and directory). This means that
the method in the site class needs to call the parent's parent method
directly without calling the parent's method. I tried both
parent::parent::method() and parent::parent -> method() but both of
these threw an error

Is there a way to call a method that's further than 1 class up the
inheritance chain?

On Nov 9, 11:37 am, Gordon <gordon.mc...@ntlworld.com> wrote:
> I am currently rewriting a corporate CMS that was originally hacked
> together in a hurry by a mamber of staff who is now leaving and which
> is totally uncommented and is therefore in a state where maintaining
> it would be a total nightmare. I'm redesigning it to take an OO
> approach, but am limited to PHP 4 on the server on which it will run
> and am therefore limited to that version's OO model.
>
> The current plan is to have a hierarchy of classes going from the
> general to the specific and inherit and override/extend functions as
> necessary to achieve the desired results. At the top of the chain is
> a CMS item object that defines props and methods that are common to
> all items that will be stored by the CMS: Creation/last modified
> dates, summaries, filesystem paths etc. From that I dreive classes
> for specific types of CMS data. Documents, images and directories all
> decend directly from the CMS item class.
>
> As I was designing I originally intended for there to be a site class
> that inherited from the item class, but as the design progressed I
> realised that a site is basically a special case of a directory and
> therefore should be derived from the directory class.
>
> But here I hit a snag, because I need to access a method in the item
> class while bypassing the same method in the directory class. In the
> item class is a method that inserts some data into the items table of
> the database. In the directory class this method is extended by
> another method of the same name. This method runs the method in the
> parent class with parent::method(), then does the extra SQL queries
> that it needs to do for creating a directory.
>
> The site class, however, uses a different pair of tables (item and
> site) to the directory class (item and directory). This means that
> the method in the site class needs to call the parent's parent method
> directly without calling the parent's method. I tried both
> parent::parent::method() and parent::parent -> method() but both of
> these threw an error
>
> Is there a way to call a method that's further than 1 class up the
> inheritance chain?

Just use $this->method() as the method is inherited down through the
hierarchy!
Enjoy,
John

Gordon wrote:
> but am limited to PHP 4 on the server on which it will run

Change that. It's totally insane to design a new software for a platform
which will be supported for less than a year from now on.

Follow-ups set to comp.object

Gordon <gordon.mcvey@ntlworld.com> wrote in
<1194601048.553776.222520@d55g2000hsg.googlegroups .com>:
> The current plan is to have a hierarchy of classes going
> from the general to the specific and inherit and
> override/extend functions as necessary to achieve the
> desired results. At the top of the chain is a CMS item
> object that defines props and methods that are common to
> all items that will be stored by the CMS: Creation/last
> modified dates, summaries, filesystem paths etc. From
> that I dreive classes for specific types of CMS data.
> Documents, images and directories all decend directly from
> the CMS item class.
>
> As I was designing I originally intended for there to be a
> site class that inherited from the item class, but as the
> design progressed I realised that a site is basically a
> special case of a directory and therefore should be
> derived from the directory class.
>
> But here I hit a snag, because I need to access a method
> in the item class while bypassing the same method in the
> directory class.

Then your design is, well, bad. What parent class extends is
its implementation detail, therefore you shouldn't rely on
it.

> In the item class is a method that inserts some data into
> the items table of the database. In the directory class
> this method is extended by another method of the same
> name. This method runs the method in the parent class
> with parent::method(), then does the extra SQL queries
> that it needs to do for creating a directory.
>
> The site class, however, uses a different pair of tables
> (item and site) to the directory class (item and
> directory).

So either make them use the same table (if Site truly is-a
Directory), or extend Item instead of Directory.

> This means that the method in the site class needs to call
> the parent's parent method directly without calling the
> parent's method. I tried both parent::parent::method()
> and parent::parent -> method() but both of these threw an
> error

I'm actually unaware if it's possible to do in PHP, because
I wouldn't do that anyway for reasons outlined above.

If you're thinking along the lines of "but Site really is a
lot like Directory" - you might as well be right, but there
are cleaner solutions to the problem. Strategy pattern
comes to mind.

--
....also, I submit that we all must honourably commit seppuku
right now rather than serve the Dark Side by producing the
HTML 5 spec.

On Nov 9, 10:32 am, Jonas Werres <jo...@example.org> wrote:
> Gordon wrote:
> > but am limited to PHP 4 on the server on which it will run
>
> Change that. It's totally insane to design a new software for a platform
> which will be supported for less than a year from now on.

I would if I could, but I'm just teh code monkey, and the system
that's being replaced has to remain operational on it. Said system
is, like I said, not coded to a very maintainable standard, and
updating the PHP version it's running under would almost certainly
cause it to break in some way.

> I would if I could, but I'm just teh code monkey, and the system
> that's being replaced has to remain operational on it. Said system
> is, like I said, not coded to a very maintainable standard, and
> updating the PHP version it's running under would almost certainly
> cause it to break in some way.

I think it's worth a try on a test system. I could migrate to PHP5 with at
least that painful scripts with compatibility_mode On, which you can enable
on directory basis.

Gordon wrote:
> On Nov 9, 10:32 am, Jonas Werres <jo...@example.org> wrote:
>> Gordon wrote:
>>> but am limited to PHP 4 on the server on which it will run
>> Change that. It's totally insane to design a new software for a platform
>> which will be supported for less than a year from now on.
>
> I would if I could, but I'm just teh code monkey, and the system
> that's being replaced has to remain operational on it. Said system
> is, like I said, not coded to a very maintainable standard, and
> updating the PHP version it's running under would almost certainly
> cause it to break in some way.
>
>

I agree with Jonas on this. At least try the old system on PHP 5. If
it was not using any of the OO features, chances are it will not require
many (if any) changes.

You need to move sooner or later. Why lock yourself into PHP with your
new code?

I also agree with Pavel - you need to look at your design again. The
fact you're running into this problem shows it's in trouble, and that
will get worse.

But I don't necessarily agree with the fup to only comp.object.

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