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 <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.
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 :)
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
