On Thu, 2009-03-19 at 22:54 -0400, Bob McConnell wrote:
> 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 <r...@cbord.com>
> 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.

Aaah, you're stuck in procedural mode. In my first year of university
they taught us both C and Smalltalk in different courses and during the
same semester (same semester for me anyways). As such, I didn't form a
bias. Unfortunately they taught us scheme the following year and while I
understand scheme, I have less of a liking for it :)

> 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.

And what is a library to you? And a library for which each function
requires on being passed a specific structure type? The structure is
merely the object, and the library routines are the methods. if you can
see libraries and structures, then you can see classes and methods.

> 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.

It's not for people to tell you how to fix it... it for you to unwire
your head and learn it yourself :)

> (*) 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). [--SNIPPITY--]
> You also failed to explain what "new" does, or "parent::__constructor".
> What is the relationship between a class and an object? [--SNIPPITY--]

I wasn't teaching your OOP, I was showing that OOP and procedural are
merely different representations of the same thing, and that the
representations aren't all that different.

>  I get frustrated
> because of the extra overhead required to instantiate an object with its
> members before they can be referenced,

If you've done C programming then you know you have to instantiate a
pointer to a structure before you should access any of it's members.
Whether you zero out the memory or actually assign values... you are
still instantiating.

>  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?

I'm not sure what you mean in the above.

> 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.

I'm sure that's a good thing :)

Application and Templating Framework for PHP

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to