Re: [PHP] OOP slow -- am I an idiot?

Tony Marston wrote:
> "Stut" <stuttle@gmail.com> wrote in message
> news:452ED193.8080707@gmail.com...
>
>> My general approach to designing a system is data-centric. I tend to start
>> by defining the database schema since getting that clear in my head tends
>> to lead me to a decent design.
>>
>
> What a coincidence! That's exactly my approach, but I've taken it one step
> further. I always start with a properly normalised database which I can then
> import into my daa dictionary application. From there I can press a button
> and create a class file for each database table, and I am ptting the
> finishing touhes to a procedure whereby I can press another button to
> generate the scripts which will maintain each table. This means I can get
> basic transactions up and running without writing a single line of code. All
> I have to do is edit these files to include business logic and any
> customisations.
>
> This level of automation is not possible with some people's OO
> implementations, so I can only conclude that their approach is not the
> optimal one.
>

Youch!! Your implementation seems to be focused on development
efficiency rather than runtime efficience. In all but rare research
projects this is backwards for a web-based system. This is exactly the
practice I am trying to discourage. It's a well-known fact that code
generators are a poor substitute for real developers.

>> For most projects I don't start out with OOP in mind, but my brain is used
>> to building OOP-style systems so nearly everything I do ends up with a few
>> classes.
>>
>
> The difference with me is that I don't waste my time with trivial websites,
> I concentrate on administrative web applications. But even when I wrote the
> code for my own website at http://www.radicore.org I still used all my
> database classes as it was far easier than doing it the traditional
> old-fashioned way

Trivial websites are where you can get away with using code generators.
For anything non-trivial I would not feel comfortable with a
jack-of-all-trades-master-of-none-style of code. Now that I think of it
I'm quite anal about the quality of my code, so I don't think I'd ever
use a code generator - never have before.

-Stut

Ed Lazor wrote:
> On Oct 12, 2006, at 4:36 PM, Stut wrote:
>> If I then go on to create an admin interface for the users, I would
>> create another completely separate class called UserCollection to
>> handle more than one user. I may at that point choose to expose any
>> data-massaging methods in User to UserCollection to avoid code
>> duplication, but that would be the extent of the way UserCollection
>> uses the User class since the User class is optimised to work on a
>> single user at any one time.
>
> We use a similar approach for the user class. I haven't ever
> implemented something like the UserCollection class though. I'm
> curious about that. Does your UserCollection class extend the basic
> user class? Or is it something else entirely; I dunno, maybe
> UserCollection has a property defined as an array of User class? I
> think that's what people were saying earlier in the thread as being a
> "very bad thing" in terms of memory utilization, etc.

Indeed, that would be a very bad thing, unless you've already considered
that. I've previously mentioned that I have an ActiveRecord-style
implementation for a lot of my DB access. The base class for that system
has a static function called FindAll which will return an array of
objects. However, it only does a single SQL statement. The base class
also has a method LoadFromArray which, shockingly, loads the object from
an array. This means that from a single DB request I can get an array of
objects each representing one entitity (potentially a row, but not
necessarily).

Bear in mind that this is not always the best solution (as ever).
Continuing the example from my previous email, I very much doubt that
the UserCollection class would contain any instances of the User class.
However, if you read back I did say that I would probably expose the
methods in the User class to massage the data, meaning that any part of
the data in the database that needs transforming before it can be used
is handled by one piece of code whether it's for single or multiple records.

> How to properly define the User class and UserCollection classes also
> seems to delve into issues of UML and CORBA, which I don't have a lot
> of experience with. Is anyone applying those technologies to PHP?

It's rare for me to use any formal system for defining my object model,
but when I do it's usually UML. If I remember correctly from my degree,
CORBA is a remoting specification so I'm not sure how it applies here.

>> This makes it perfect for an object-per-record implementation since
>> there is only one record.
>
> Yea, but I keep thinking back to how the implementation of data
> representation is separate from the implementation of how that data is
> used. Going back to the users example, I created a User class. I
> never bothered to create a UserCollection class because coding that
> does anything with a collection of users typically ends up being
> situational. Say I want a list of customers. I could create a
> UserCollection class with a method called list... and I could have it
> query the db and dump general fields. That seems like a fairly
> generic approach, so it might work, but I usually want to do something
> with individual fields - like link to a specific webpage to view more
> information on the customer, edit the customer record, delete, etc..
> I know I could code all of these features into the class... but it
> reaches the point where it seems like overkill. It seems better to
> just create a webpage that has code to handle that.... which is what I
> end up doing. Mind you, I once created a bunch of classes that did
> all of the cool "pretty" formatting, table layout, with customizable
> doohikies, but that's where the classes started getting bloated, the
> system started bogging down, and there were very small, but very
> noticeable, delays in loading pages. I guess that leads me back to
> wondering how you implemented the UserCollection class or, at least,
> what features you built into it in order for it to be of benefit. I'm
> also assuming (uhoh hehe) that the same thing applies to other object
> hierarchies - for example, one class that defines a product and
> another class that defines a collection of products.... wondering how
> the two would be implemented to maintain efficiency... and I'm
> guessing your answer is that how you implement it depends on the
> situation... whether the site focuses on using individual products the
> most or ends up working with collections of products most... but it
> seems like it wouldn't matter... ie. again, the separation of data
> from implementation.

"Situational" - that's a term I've never heard in this context before.
To me what you're describing is evil. I use OOP to wrap data such that I
can access it in a consistent manner from anywhere. The only SQL I ever
write is in classes. While it's true that I could do everything I do
with OOP functionally, using OOP forces me to think about how data and
operations on data are connected.

>> Having said that, it doesn't apply too much where PHP is concerned
>> unless you are developing a set of classes for public consumption.
>> What is more important is that by packaging data and logic together
>> you end up with one place where it all happens, and you can choose
>> how much of the internal workings are exposed to the rest of the system.
>
> The only difference here is that I'd probably aim for all classes to
> be good enough for public consumption, but I know that takes more time
> in development.

For me it's not a case of taking more time in development. Due to the
nature of PHP, the way a particular class is used, its context, is more
important to me than making it generic. I'll advocate code reuse until
I'm blue in the face, but when performance is one of the main goals
there is often little choice but to rewrite code to fit a particular
situation. This is one of the reasons I steer clear of libraries like
PEAR for anything but trivial sites - I can't guarantee that third party
code will not adversely affect the overall performance of the site. In
addition I've found that 9 times out of 10 it's quicker in the long run
to just implement it myself - at least then I know exactly what it's
doing and how, which makes it easier to fix and optimise later.

>> To relate that twoddle to PHP... OOP is a stable, mature methodology.
>> However, OOP in PHP is fairly new (if you ignore PHP4's pitiful
>> efforts) and there's still a lot of unease about this new kid on the
>> block, along with a lot of hype around the idea that it will launch
>> PHP into being a "real" programming language instead of just a
>> "web-based toy" (can't recall where I read that, otherwise I'd
>> provide a reference).
>
> Yea, that's why I was making sure to get PHP5. It seems like
> providers are still lagging in implementing it tho?

If by providers you mean hosts then you're right. I actually run a
hosting company and can only offer PHP5 because we recently went through
a process of upgrading all our servers (painful that was!!) and a
customer survey showed that over 90% of them wanted the upgrade - 13%
said they were likely to switch provider within 6 months if we did not
upgrade.

However, I do know that making such a move can be incredibly expensive,
not only in obvious engineer time required to simply do the upgrade but
the resulting support costs will be an order of magnitude greater even
if the upgrades themselves go very smoothly.

I'm in a very fortunate position in that nearly all of my clients fall
into one of two camps... those that are competent developers, and those
with simple static sites.

>> I'd quite like an opinion from a Zend Engine developer here. As I've
>> previously mentioned I primarily work with a fairly large OOP-based
>> system but haven't noticed any great performance drain. While it's
>> true that we use Zend Platform on both our development and production
>> servers that's purely due to the sheer number of files involved in
>> each request - something that would still be a problem if it were
>> 100% procedural. And even without the platform enabled it's not
>> particularly sluggish.
>
> Are you at liberty to talk more about the OOP-based system you use?
> It is a PHP developer sweet or something? I've seen a few, but I've
> never used them.

I don't use any third party code unless it's something I cannot
implement or don't have the time to implement - both of which are
thankfully quite rare. PHP frameworks are great if you want rapid
development and your system fits nicely into the common structure, but
they suck arse if you want to do anything even slightly different.

I actually use two different code structures - one at my day job which I
can't say too much about (except that it's a mess by way of much
incremental development), and the one I use for most of my
personal/business sites. I'm currently writing an article describing the
latter - I'll post a link to this list when it's finished if people are
really interested.

-Stut

On 10/13/06, Stut <stuttle@gmail.com> wrote:
> Ed Lazor wrote:
> > ...Or is it something else entirely; I dunno, maybe
> > UserCollection has a property defined as an array of User class? I
> > think that's what people were saying earlier in the thread as being a
> > "very bad thing" in terms of memory utilization, etc.

I'm honestly having a difficult time thinking of any way *other* than
having an array of User objects. In previous projects I've tried the
route of (like Richard mentioned early on):

class Customers {
var $ids = array();
var $names = array();
}

But found it very cumbersome and unintuitive when dealing with a
single Customer. Moreso I got lost when I didn't know if I were
dealing with one or many customers...

As soon as I went to a Customer and CustomerCollection approach, I was
able to make sense of it all. Even though CustomerCollection usually
didn't actually exist, except conceptually as an array of Customer
objects within my application code. Like Stut suggested, I too have
static fetch functions derived from the base ActiveRecord class that
return arrays of objects.

Maybe all of my applications have been "simple" enough in that I
tended to work on single objects 95% of the time, and therefore
creating interfaces for those single objects made sense. I think
that's what Ed means by situational?

It is occuring to me that perhaps all of my bias is centered around
the fact that I always create my models as children of an ActiveRecord
class, which is by nature based on *one record* of a table.

Is there an ActiveTable class that, if implemented, might completely
change everything???

Until then, I'm not convinced: constructing a basic building block
such as a Customer, and then an aggregate block such as a collection
of Customers, and so on, seems the most stable and scalable approach
almost without exception...and perhaps, with that, I'm revealing the
extent of my OOP naivety...

John W

On Oct 13, 2006, at 1:35 AM, Tony Marston wrote:
> What a coincidence! That's exactly my approach, but I've taken it
> one step
> further. I always start with a properly normalised database which I
> can then
> import into my daa dictionary application. From there I can press a
> button
> and create a class file for each database table, and I am ptting the
> finishing touhes to a procedure whereby I can press another button to
> generate the scripts which will maintain each table. This means I
> can get
> basic transactions up and running without writing a single line of
> code. All
> I have to do is edit these files to include business logic and any
> customisations.

Is the Radicore framework still available?

-Ed

On Oct 13, 2006, at 1:54 AM, Stut wrote:
> Youch!! Your implementation seems to be focused on development
> efficiency rather than runtime efficience. In all but rare research
> projects this is backwards for a web-based system. This is exactly
> the practice I am trying to discourage. It's a well-known fact that
> code generators are a poor substitute for real developers.

I agree with Stut, but I'd also like to check out a copy of the
framework. It seems like a lot of people are using frameworks now
days and I can't help but wonder if they provide similar performance
as the OOP library that Stut uses.

-Ed

"Stut" <stuttle@gmail.com> wrote in message
news:452F5447.1060205@gmail.com...
> Tony Marston wrote:
>> "Stut" <stuttle@gmail.com> wrote in message
>> news:452ED193.8080707@gmail.com...
>>
>>> My general approach to designing a system is data-centric. I tend to
>>> start by defining the database schema since getting that clear in my
>>> head tends to lead me to a decent design.
>>>
>>
>> What a coincidence! That's exactly my approach, but I've taken it one
>> step further. I always start with a properly normalised database which I
>> can then import into my daa dictionary application. From there I can
>> press a button and create a class file for each database table, and I am
>> ptting the finishing touhes to a procedure whereby I can press another
>> button to generate the scripts which will maintain each table. This means
>> I can get basic transactions up and running without writing a single line
>> of code. All I have to do is edit these files to include business logic
>> and any customisations.
>>
>> This level of automation is not possible with some people's OO
>> implementations, so I can only conclude that their approach is not the
>> optimal one.
>>
>
> Youch!! Your implementation seems to be focused on development efficiency
> rather than runtime efficience.

Precisely. That is why I said it was adminstrative web applications which
typically have far fewer users than web sites.

> In all but rare research projects this is backwards for a web-based
> system.

Wrong again. This is for administrative web applications, the type that were
previously built as desktop applications. Their function is to get data into
and out of a database i.e. CRUD applications), not to serve thousands of
casual vuisitors.

> This is exactly the practice I am trying to discourage. It's a well-known
> fact that code generators are a poor substitute for real developers.

It depends how you go about it. My code generators fulfil the basics, then
the programmer's job is to customise it.

>>> For most projects I don't start out with OOP in mind, but my brain is
>>> used to building OOP-style systems so nearly everything I do ends up
>>> with a few classes.
>>>
>>
>> The difference with me is that I don't waste my time with trivial
>> websites, I concentrate on administrative web applications. But even when
>> I wrote the code for my own website at http://www.radicore.org I still
>> used all my database classes as it was far easier than doing it the
>> traditional old-fashioned way
>
> Trivial websites are where you can get away with using code generators.
> For anything non-trivial I would not feel comfortable with a
> jack-of-all-trades-master-of-none-style of code. Now that I think of it
> I'm quite anal about the quality of my code, so I don't think I'd ever use
> a code generator - never have before.

I have never liked any of the code generators I have seen created by others,
but with my general-purpose framework I noticed that a lot of the code that
I was generating by hand followed a familiar pattern. It was then a simple
exercise to write a program to generate this same code on command.

Be aware that I am not attempting to generate *all* the code that an
application will need, just the basics to get it functioning. This takes
all the drudgery out of the job and leaves the programmer to do the
interesting bits.

--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org

"Stut" <stuttle@gmail.com> wrote in message
news:452F5DA6.9070103@gmail.com...
> Ed Lazor wrote:
>> On Oct 12, 2006, at 4:36 PM, Stut wrote:
>>> If I then go on to create an admin interface for the users, I would
>>> create another completely separate class called UserCollection to handle
>>> more than one user. I may at that point choose to expose any
>>> data-massaging methods in User to UserCollection to avoid code
>>> duplication, but that would be the extent of the way UserCollection uses
>>> the User class since the User class is optimised to work on a single
>>> user at any one time.
>>
>> We use a similar approach for the user class. I haven't ever implemented
>> something like the UserCollection class though. I'm curious about that.
>> Does your UserCollection class extend the basic user class? Or is it
>> something else entirely; I dunno, maybe UserCollection has a property
>> defined as an array of User class? I think that's what people were
>> saying earlier in the thread as being a "very bad thing" in terms of
>> memory utilization, etc.
>
> Indeed, that would be a very bad thing, unless you've already considered
> that. I've previously mentioned that I have an ActiveRecord-style
> implementation for a lot of my DB access. The base class for that system
> has a static function called FindAll which will return an array of
> objects. However, it only does a single SQL statement. The base class also
> has a method LoadFromArray which, shockingly, loads the object from an
> array. This means that from a single DB request I can get an array of
> objects each representing one entitity (potentially a row, but not
> necessarily).

The very idea of one object per row makes me want to throw up. I have one
object per table, and each object can deal with any number of rows. I don't
use getters and setters to access the columns from any row, I simply input
an array (typically one row from the $_POST array) and output an array which
may contain any number of rows. I find this to be far easier and no less
efficient.

--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org

"Ed Lazor" <edlazor@yahoo.com> wrote in message
news:EA647CF2-CA85-4D35-A18C-9D96731CED26@yahoo.com...
>
> On Oct 13, 2006, at 1:35 AM, Tony Marston wrote:
>> What a coincidence! That's exactly my approach, but I've taken it one
>> step
>> further. I always start with a properly normalised database which I can
>> then
>> import into my daa dictionary application. From there I can press a
>> button
>> and create a class file for each database table, and I am ptting the
>> finishing touhes to a procedure whereby I can press another button to
>> generate the scripts which will maintain each table. This means I can
>> get
>> basic transactions up and running without writing a single line of code.
>> All
>> I have to do is edit these files to include business logic and any
>> customisations.
>
> Is the Radicore framework still available?

What do you mean *still*? Since I released it I have never closed it down. I
am still working on it and releasing improvements. I am just about to
release some new functionality which will generate more standard code for
each transaction. Watch my website (see link in my signature) for an
announcement.

--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org

"Ed Lazor" <edlazor@yahoo.com> wrote in message
news:50BC520B-9A78-4E9B-B32F-ABCAEFA2F229@yahoo.com...
>
> On Oct 13, 2006, at 1:54 AM, Stut wrote:
>> Youch!! Your implementation seems to be focused on development
>> efficiency rather than runtime efficience. In all but rare research
>> projects this is backwards for a web-based system. This is exactly the
>> practice I am trying to discourage. It's a well-known fact that code
>> generators are a poor substitute for real developers.
>
> I agree with Stut, but I'd also like to check out a copy of the
> framework. It seems like a lot of people are using frameworks now days
> and I can't help but wonder if they provide similar performance as the
> OOP library that Stut uses.

If you want to build administrative web applications which have a small
number of users, and where development costs are more important than
performance of execution (i.e. developer cycles over cpu cycles) then check
out RADICORE at http://www.radicore.org It is better than Ruby on Rails.

--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org

As I cannot think of a class-based way to build my report, I think I'll use a customer class
everywhere BUT in the report. Inside the report I'll just use one SQL statement instead of dozens
of instances and hundreds of queries.

I'll make a note inside the class that this and that method is not the only place the data is
accessed, to also check inside the report.

Sometimes, you've just gotta compromise to get the job done. Most of the time, OOP is a good
idea, but in this instance I don't think it's the best choice.

It's less elegant but more pragmatic. Our project is medium-sized (only about 10K lines) and this
will work just fine. (It makes me wonder if enterprise-class OO projects had to make the same
decisions.)


Thanks to everyone for your input. I need to unsubscribe from the list, so if you have any input,
please CC: Chris (AT) deVidal (DOT) tv (my real email address). You might get an automatic reply,
click the link.

CD

Think you're a good person? Yeah, right! ;-)
Prove it and get ten thousand dollars:
TenThousandDollarOffer.com