RE: [PHP] Smarty Tips and Techniques

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@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 :) Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP