Is OOP really appropriate for PHP?

Hi folks,

I have a basic question. When I do object-oriented programming
using C++ or Java, all my objects reside in RAM. I do not have
to think about storing and retrieving them, because they are
in RAM and that space has been allocated for them and
the program is continually running, so neither program nor
objects are going to disappear.

It seems to me, having never done OOP in PHP, that this
arrangement would not exist in PHP, because program+objects
only exist when a page is being constructed. In the meantime,
where are the objects? You might say, "in my MySQL database",
and that is certainly a capable storage medium, however
it takes time to get them out, and to store them back into it.

So the question is, I think, appropriate. Since PHP has
(AFAIK) no object storage other than a database, is
OOP in PHP really appropriate?

If there is some other storage medium can you tell me what it is?

If there isn't another faster storage medium than a database,
why doesn't someone create one, to improve efficiency?

Thanks.

Re: Is OOP really appropriate for PHP?

> I have a basic question. When I do object-oriented programming
> using C++ or Java, all my objects reside in RAM. I do not have
> to think about storing and retrieving them, because they are
> in RAM and that space has been allocated for them and
> the program is continually running, so neither program nor
> objects are going to disappear.

Well, web applications exist discontinuously, like as a film. But that
does not change anything in the need for object orientation.

> It seems to me, having never done OOP in PHP, that this
> arrangement would not exist in PHP, because program+objects
> only exist when a page is being constructed. In the meantime,
> where are the objects? You might say, "in my MySQL database",
> and that is certainly a capable storage medium, however
> it takes time to get them out, and to store them back into it.

In that meantime, the objects simply do not exist. The in-between
pictures of a film do not exist either. So your objects must be
retrieved and stored fast. But apart from that speed, the mechanisms are
exactly the same as for local applications.

> So the question is, I think, appropriate. Since PHP has
> (AFAIK) no object storage other than a database, is
> OOP in PHP really appropriate?

It may be even more appropriate. Object orientation allows you to
optimize the database communication strategy (greedy, lazy, or something
in-between). This optimization helps you with every request, and not
only upon the startup of your application. If fact, your application is
restarted at every server request.

> If there is some other storage medium can you tell me what it is?

You can store objects or object data in a session. This is the most
straightforward way to make your application seem to be running
continuously.

Best regards

Re: Is OOP really appropriate for PHP?

On Dec 2, 2:56 pm, Viator wrote:
> Hi folks,
>
> I have a basic question. When I do object-oriented programming
> using C++ or Java, all my objects reside in RAM. I do not have
> to think about storing and retrieving them, because they are
> in RAM and that space has been allocated for them and
> the program is continually running, so neither program nor
> objects are going to disappear.
>
> It seems to me, having never done OOP in PHP, that this
> arrangement would not exist in PHP, because program+objects
> only exist when a page is being constructed. In the meantime,
> where are the objects? You might say, "in my MySQL database",
> and that is certainly a capable storage medium, however
> it takes time to get them out, and to store them back into it.
I am a bit confused here. In PHP, the objects are created and stored
in the Server's RAM as the script runs (when the webpage is
constructed), and as the script finishes execution, the objects are
wiped from the memory (which is a really quick process).

>
> So the question is, I think, appropriate. Since PHP has
> (AFAIK) no object storage other than a database, is
> OOP in PHP really appropriate?
>
> If there is some other storage medium can you tell me what it is?
>
> If there isn't another faster storage medium than a database,
> why doesn't someone create one, to improve efficiency?
>
> Thanks.

--
Kailash Nadh | http://kailashnadh.name

Re: Is OOP really appropriate for PHP?

Viator wrote:
> Hi folks,
>
> I have a basic question. When I do object-oriented programming
> using C++ or Java, all my objects reside in RAM. I do not have
> to think about storing and retrieving them, because they are
> in RAM and that space has been allocated for them and
> the program is continually running, so neither program nor
> objects are going to disappear.
>
> It seems to me, having never done OOP in PHP, that this
> arrangement would not exist in PHP, because program+objects
> only exist when a page is being constructed. In the meantime,
> where are the objects? You might say, "in my MySQL database",
> and that is certainly a capable storage medium, however
> it takes time to get them out, and to store them back into it.
>
> So the question is, I think, appropriate. Since PHP has
> (AFAIK) no object storage other than a database, is
> OOP in PHP really appropriate?
>
> If there is some other storage medium can you tell me what it is?
>
> If there isn't another faster storage medium than a database,
> why doesn't someone create one, to improve efficiency?
>
> Thanks.

Your problem is web programming requires a different design.

Web pages are transactional in nature. That is, the browser makes a
request, the page starts, processes the request and terminates (one
transaction). When the user does something to create another request,
the process repeats.

Most C/C++ programs are not like this - they start and keep going across
multiple requests.

But this does not affect OO design and usage. It is still very much
appropriate for transactional programming. You don't have to save the
objects to make them useful.

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

Re: Is OOP really appropriate for PHP?

On 2 Dec, 14:56, Viator wrote:
> Hi folks,
>
> I have a basic question. When I do object-oriented programming
> using C++ or Java, all my objects reside in RAM. I do not have
> to think about storing and retrieving them, because they are
> in RAM and that space has been allocated for them and
> the program is continually running, so neither program nor
> objects are going to disappear.
>
As the other correspondents have pointed out - that is the case with
PHP as long as the current thread is being executed. It is also true
of Java and C++ when invoked as a new execution thread via CGI - most
commonly for Java complex applications are implemented via containers
where a significant part of the process continues after the request
thread is completed.

You shouldn't have to think too much about storing/retrieving data
with PHP - read up on sessions. This of course does not address the
class definition part of an object - you can manually reference the
definitions within your code but its a lot simpler to adopt a
consistent approach to where you keep these and use the autoload
functionality (loading of a definition of a class instantiated in the
session is deferred).

> however
> it takes time to get them out, and to store them back into it.
>

Most Web based Java applications have a similar problem/overhead
because the session has to replicate across the nodes - IME this is
much more painful than PHP's session handling which is intrinsically
at the storage layer.

(I also have a pet peeve about ORM - I think its a bad idea)

> So the question is, I think, appropriate. Since PHP has
> (AFAIK) no object storage other than a database, is
> OOP in PHP really appropriate?
>

You don't have to use a database. By default sessions are stored on
the filesystem but you can put them anywhere you can access via PHP -
a database or shared memory are obvious candidates. The filesystem can
easily be in RAM if you like.

Why do you think it's not fast enough?

C.

Re: Is OOP really appropriate for PHP?

On Dec 2, 2:56 pm, Viator wrote:
> Hi folks,
>
> I have a basic question. When I do object-oriented programming
> using C++ or Java, all my objects reside in RAM. I do not have
> to think about storing and retrieving them, because they are
> in RAM and that space has been allocated for them and
> the program is continually running, so neither program nor
> objects are going to disappear.
>
> It seems to me, having never done OOP in PHP, that this
> arrangement would not exist in PHP, because program+objects
> only exist when a page is being constructed. In the meantime,
> where are the objects? You might say, "in my MySQL database",
> and that is certainly a capable storage medium, however
> it takes time to get them out, and to store them back into it.
>
> So the question is, I think, appropriate. Since PHP has
> (AFAIK) no object storage other than a database, is
> OOP in PHP really appropriate?
>
> If there is some other storage medium can you tell me what it is?
>
> If there isn't another faster storage medium than a database,
> why doesn't someone create one, to improve efficiency?
>
> Thanks.

OOP is far from just a memory management strategy, it is also about
how code is organized. Building an application out of smaller self-
contained objects and adding functionality through inheritance are
considered good practice in programming these days because it makes it
far more difficult to write unmaintainable spaghetti code that way
(though it is still far from impossible :) ). For example I'm writing
a CMS type application. All the data the CMS will work with has a lot
of things in common (the need for a timestamp and a path to be stored,
for example), but several different classes of objects have different
properties. For example a folder can hold other items whereas a
document cannot, but a document can have written text content whereas
a directory cannot. For this reason I've created a generic CmsItem
class that implements all the functionality that is common to both and
then built a CmsDir and CmsDoc class that both inherit for CmsItem and
which provide functionality pertinant to folders and documents,
respectivly.

The system it is replacing has very little structure and is so
difficult to maintain that it has been decided that a complete rewrite
is a worthwhile exercise.

While an instance will only last for as long as a page generation
operation (you can think of that as a transaction) is in progress, you
can, if you need to, serialize objects and store their props in a
session or the database as needed. Regardless of the approach you
take (OO or SP) you'll still have to store the data you want to
preserve across transactions anyway.