Stut wrote:
This is a question of design, not a question of whether to use OOP.
For example, in several of the sites I maintain I have classes that
inherit from a base class called Table. The base class provides a lot
of the basic methods for working on a table (think ActiveRecord). It
also
# [EMAIL PROTECTED] / 2006-10-15 13:59:39 -0700:
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
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
Stut [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Tony Marston wrote:
Stut [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
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
Stut [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
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
Ed Lazor [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
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
Ed Lazor [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
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.
Please include the list when replying to that others may benefit (or
suffer) from the discussion.
Bruce Cowin wrote:
I like your static user class. Does the user instance then get saved to a
session variable that is serialized/unserialized on every page?
There is no user instance as
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
On 10/13/06, Stut [EMAIL PROTECTED] 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
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
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
# [EMAIL PROTECTED] / 2006-10-12 06:49:22 +0100:
Roman Neuhauser wrote:
# [EMAIL PROTECTED] / 2006-10-11 21:28:36 +0100:
Richard Lynch wrote:
This is a classic example of the obvious OOP solution being wildly
inappropriate.
Ok, so I now find myself in the unusual position of disagreeing with
Roman Neuhauser [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
# [EMAIL PROTECTED] / 2006-10-11 21:28:36 +0100:
Richard Lynch wrote:
On Tue, October 10, 2006 6:14 pm, Chris de Vidal wrote:
I want to create a customer class which fetches its attributes from
a MySQL database.
No,
By the way, about myself. I'm primarily a system administrator. Most of the
time I USE code, NOT
write it. But I also dabble, and right now we need to improve our old custom
PHP revenue
application which has sat stagnant for a few years. We can't afford a
full-time programmer and I
know
On Wed, October 11, 2006 3:28 pm, Stut wrote:
Richard Lynch wrote:
On Tue, October 10, 2006 6:14 pm, Chris de Vidal wrote:
I want to create a customer class which fetches its attributes
from
a MySQL database.
No, you don't. :-)
This is a classic example of the obvious OOP solution being
On Thu, October 12, 2006 12:49 am, Stut wrote:
Roman Neuhauser wrote:
# [EMAIL PROTECTED] / 2006-10-11 21:28:36 +0100:
Richard Lynch wrote:
On Tue, October 10, 2006 6:14 pm, Chris de Vidal wrote:
I want to create a customer class which fetches its attributes
from
a MySQL database.
No, you
On Thu, October 12, 2006 3:11 am, Tony Marston wrote:
I have to disagree as well. There is absolutely nothing wrong which
the
approach of creating one class for each table in the database. It
cannot be
wrong for the simple reason THAT IT WORKS!
Only problem is that then you often end up
On Thu, October 12, 2006 8:24 am, Chris de Vidal wrote:
[use the archives]
I can't architect a good OOP solution to a problem that hasn't been
fully defined, any more than one can architect a house without knowing
all the rooms that are needed...
I agree that all the code samples you provided
On Oct 12, 2006, at 10:18 AM, Richard Lynch wrote:
I can't architect a good OOP solution to a problem that hasn't been
fully defined, any more than one can architect a house without knowing
all the rooms that are needed...
Sorry to jump into the middle of the conversation, but I thought this
Richard Lynch wrote:
I *still* don't see OOP as a Right Answer for spitting out HTML web
pages in optimized minimalist time frames...
Maybe my brain just got warped by all that AI/Lisp work I did for a
couple decades, but it feels to me like a bad selection of weapons for
the task at hand, most
Ed Lazor wrote:
On Oct 12, 2006, at 10:18 AM, Richard Lynch wrote:
I can't architect a good OOP solution to a problem that hasn't been
fully defined, any more than one can architect a house without knowing
all the rooms that are needed...
Sorry to jump into the middle of the conversation,
On Thu, October 12, 2006 1:03 pm, Ed Lazor wrote:
On Oct 12, 2006, at 10:18 AM, Richard Lynch wrote:
I can't architect a good OOP solution to a problem that hasn't been
fully defined, any more than one can architect a house without
knowing
all the rooms that are needed...
Sorry to jump into
# [EMAIL PROTECTED] / 2006-10-12 16:29:09 -0500:
On Thu, October 12, 2006 1:03 pm, Ed Lazor wrote:
On Oct 12, 2006, at 10:18 AM, Richard Lynch wrote:
I can't architect a good OOP solution to a problem that hasn't been
fully defined, any more than one can architect a house without
knowing
Comments / Questions below.
On Oct 12, 2006, at 12:15 PM, Stut wrote:
Except that is the attitude that leads to painful OOP in PHP. PHP
is not the same environment as C++.
The environment (classes, objects, etc) needs to be created and
destroyed with each request.
I definitely agree that
Richard Lynch [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
On Thu, October 12, 2006 3:11 am, Tony Marston wrote:
I have to disagree as well. There is absolutely nothing wrong which
the
approach of creating one class for each table in the database. It
cannot be
wrong for the
Ed Lazor wrote:
On Oct 12, 2006, at 12:15 PM, Stut wrote:
As such you cannot start designing a solution unless you know how the
data/entities are going to be used.
Doesn't this mean that your design breaks when the behavior or use of
the data/entities changes?
You may end up refactoring
On Oct 12, 2006, at 4:36 PM, Stut wrote:
You may end up refactoring code if your application changes that
much, but a good OO design should also mean that when changes of
that magnitude occur the changes required are limited to relatively
small sections of code.
Ok, I think we're using
--- Johan Martin [EMAIL PROTECTED] wrote:
You should look into getting Professional PHP5 by Lecky-Thompson,
Eide-Goodman, Nowicki and Cove from WROX.
...
The collection class in chapter 5 discusses a programming problem
just like yours.
I will look into that, thank you.
CD
Think
--- Larry Garfield [EMAIL PROTECTED] wrote:
For your rudimentary example of object-relational mapping below, yes,
performance is going to be atrocious. That's because you're not taking any
advantage of the features that using OOP gives you.
Well, I /thought/ I was taking advantage of black
- Original Message -
From: Chris de Vidal [EMAIL PROTECTED]
To: php-general@lists.php.net
Sent: Wednesday, October 11, 2006 12:42 PM
Subject: Re: [PHP] OOP slow -- am I an idiot?
--- Johan Martin [EMAIL PROTECTED] wrote:
You should look into getting Professional PHP5 by Lecky
On Tue, October 10, 2006 6:14 pm, Chris de Vidal wrote:
I want to create a customer class which fetches its attributes from
a MySQL database.
No, you don't. :-)
This is a classic example of the obvious OOP solution being wildly
inappropriate.
The sad thing is, there are a zillion applications
Richard Lynch wrote:
On Tue, October 10, 2006 6:14 pm, Chris de Vidal wrote:
I want to create a customer class which fetches its attributes from
a MySQL database.
No, you don't. :-)
This is a classic example of the obvious OOP solution being wildly
inappropriate.
Ok, so I now find myself
# [EMAIL PROTECTED] / 2006-10-11 21:28:36 +0100:
Richard Lynch wrote:
On Tue, October 10, 2006 6:14 pm, Chris de Vidal wrote:
I want to create a customer class which fetches its attributes from
a MySQL database.
No, you don't. :-)
This is a classic example of the obvious OOP solution
Roman Neuhauser wrote:
# [EMAIL PROTECTED] / 2006-10-11 21:28:36 +0100:
Richard Lynch wrote:
On Tue, October 10, 2006 6:14 pm, Chris de Vidal wrote:
I want to create a customer class which fetches its attributes from
a MySQL database.
No, you don't. :-)
This is a classic example of the
I think perhaps I'm using classes and OOP incorrectly. The last time I used
them, they were slow.
I want to create a customer class which fetches its attributes from a MySQL
database. Something
like this pseudocode:
class customer
{
...
getName ($id)
{
$result =
Chris de Vidal wrote:
I think perhaps I'm using classes and OOP incorrectly. The last time I used
them, they were slow.
The examples you provided shows that it's not OOP that's the problem,
it's how your getting the data as you suspected.
Doing tons of queries is going to be slow whether
For your rudimentary example of object-relational mapping below, yes,
performance is going to be atrocious. That's because you're not taking any
advantage of the features that using OOP gives you. One could write a
dissertation on this problem, but I will just give you some general
On 10 Oct 2006, at 4:14 PM, Chris de Vidal wrote:
I think perhaps I'm using classes and OOP incorrectly. The last
time I used them, they were slow.
I want to create a customer class which fetches its attributes
from a MySQL database. Something
like this pseudocode:
class customer
39 matches
Mail list logo
