From: Robert Cummings
>On Thu, 2009-03-19 at 12:14 -0400, Bob McConnell wrote:
>> From: Bastien Koert
>> > On Thu, Mar 19, 2009 at 11:06 AM, Bob McConnell <rvm@xxxxxxxxx>
wrote:
>> >
>> > From: Virgilio Quilario
Most discussion clipped for brevity
> // OOP
>
> class DbFireman extends DbPerson
> {
> private $fireman;
>
> function DbPerson( $id )
> {
> parent::__constructor( $id );
> $this->fireman = load_stuff_for_fireman_from_db();
> }
>
> function getStationId()
> {
> return $this->fireman['stationId'];
> }
>
> function setName( $name )
> {
> $this->fireman['stationId'] = $stationId;
> }
> }
>
> $fireman = new DbFireman( 1234 );
> $fireman->setStationId( 'Bob' );
> echo $fireman->getStationId();
>
> ?>
>
> So as you can see they're almost identical except that the OOP version
> of fireman didn't need to redeclare functions. True you could have
> skipped doing that if you just used the person functions, but then you
> may introduce onconsistencies. Additionally, the class version ensures
> that the methods applied are those bleong to the concept of "fireman"
> whereas passing data structures around can easily get confusing,
> especially if you choose to allow the person functions to be applied
to
> the fireman. Going futher, using OOP let's you do all sorts of generic
Hi Rob,
Unfortunately, you still don't understand the problem I have. While it
takes a while to puzzle out the details, I don't have any trouble
reading, understanding or debugging code like this, even though you
skipped completely over several major components (*). I have even
modified existing methods and made minor adjustments to classes, _once
they have been written_.
What I can't do is take a problem description and turn it into classes
that will actually solve the problem. I can usually turn it into
procedures relatively quickly. I can and have built real-time,
multi-tasking and multi-threaded applications on a variety of kernels
and operating systems with no significant trouble. I have written device
drivers, interrupt service routines, message queues and I/O buffering
routines without spending a lot of time thinking about them.
But defining objects and then figuring out how to create and use them
completely escapes me. My mind simply won't map a problem into objects,
it only sees procedures. Even when I look at classes, they resolve only
as loose groupings of functions and variables, not as unified
components.
If anyone knows how to fix that, please tell me. In the meantime, in my
continuing effort to eschew obfuscation, I will stick with procedural
programming.
Bob McConnell
(*) For example, "$this->" suggests you have added an array of pointers.
Some are pointers to functions (aka methods) others are pointers to
variables (aka members). But there is no indication where this array
came from, what it means, nor how it affects the code structure. From
experience I know that "$this->" is not always needed, but the C++ rules
for when it is or isn't are neither clear nor consistent. There are no
declarations nor assignments for it. It simply adds another level of
obfuscated dereferencing that needs to be done in my head to understand
what is going on.
You also failed to explain what "new" does, or "parent::__constructor".
What is the relationship between a class and an object? I get frustrated
because of the extra overhead required to instantiate an object with its
members before they can be referenced, instead of simply being able to
use them at any time from anywhere in my code. Likewise, having to pass
a pointer for one object to another object before the second can call
the first is also counter-intuitive. They're all part of the same
application, why doesn't the compiler take care of those details like it
should?
Obviously, I don't expect answers for these questions, but hopefully
this will give you a better understanding of the greater issues
involved. This is a far cry from the Fortran IV I was taught in college
40 years ago. B.M.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
