RE: SuperQ functionality with the STANDARD core (Re: MVC question)

[BORKMAN Lee]

Title: Message

Oh, true enough about encapsulation, Hal.  Yet, as Patrick would no doubt point out, Fusebox basically gets by by passing variables around in global scopes.  I am sure that this is one of the objections that some people have to Fusebox in the first place.  It is, of course, a concern that Fusedocs have done much to alleviate, thanks to you.   But the FuseQ functions, as you have yourself said, and I agree, are convenient because the called fuseactions run in the same variable space.  There is encapsulation, and there is encapsulation ;-)   Of course, I wouldn't agree that having a child cfinclude the parent amounts to reverse inheritance.  It seems a pretty clear example of the child inheriting the parent's fuseactions to me.  But as has been said many times by cigar-lovers the world over, let's be wary about trying to treat Fusebox like it's OO - the concepts don't quite meet in the middle, and we often succeed only in muddying the waters.   You and John have done a great job, and a very large job, in creating the FuseQ extensions, just as you all did a great job in creating FB3.  But as several old-timers have pointed out, there were ways to do FB3-style things long before FB3 existed, and so there were ways to do FuseQ-style things before FuseQ existed.  It would be sad to dismiss them all as "funky" "tricks" ;-)   Thanks heaps, LeeBB ps., you haven't lived until you've tried a good New Zealand cigar... -----Original Message----- From: hal helms [mailto:[EMAIL PROTECTED]] Using a global variable and then calling the parent as you've done IMHO violates the principle of encapsulation. In your example, a much better idea would be to pass "description" as an argument. Here's a more real world situation:   I want to create a SalariedEmployee. In order to do so, I want to create a generic Employee first and get an employeeID returned to me. With that information, I can then fill in the part that's specific to a SalariedEmployee. When I want to create a new SalariedEmployee, I first call SuperQ(). Same with ContractEmployee. The idea is that HourlyEmployee, SalariedEmployee, and ContractEmployee are all types of Employee and I want to abstract the code common to all three types of employees to the super type, Employee, so that I don't have code duplication.   This is how Super() is used most commonly in languages like Smalltalk and Java. In the case I describe, I definitely want the parent's fuseaction to run in the context the architect intended it to be. What you're describing is a sort of reverse inheritance where the parent inherits from the child. That is downright funky. However, I will take you up on the brandy and fine Cuban cigars. ;-) -----Original Message----- From: BORKMAN Lee [mailto:[EMAIL PROTECTED]] But Hal, if you want the parent's fuseaction to run in exactly the same way as if the parent were being called directly, why not just invoke the parent directly?  That's surely the simple way to ensure "that the parent will operate in the environment it was designed to."   Let's just imagine a simple example: We have an environment variable called "request.description". We have a circuit called "human" and it has two child circuits, "Lee" and "Hal". The "Human" circuit has a single fuseaction "showDescription" that simply outputs #request.description# In Human's fbx_settings, request.description="I understand sentence structure, and can imagine the world without me in it." In Lee's fbx_settings, request.description="I don't understand America date formats." In Hal's fbx_settings, request.description="I like expensive cigars"   Now, when the user calls "fuseaction=human.showdescription", they get "I understand sentence structure, and can imagine the world without me in it."   So what result do you expect/want when the user calls "fuseaction=hal.showdescription"? I want it to say "I like expensive cigars."  That's what a simple cfinclude will do. Using SuperQ(), it will say "I understand sentence structure, and can imagine the world without me in it." Anyway, this is probably not a discussion for this list.  We'll have to thrash this one out over a couple of brandy snifters, and some Cuban contraband.     ==^================================================================ This email was sent to: archive@jab.org EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrFMa.bV0Kx9 Or send an email to: [EMAIL PROTECTED] T O P I C A -- Register now to manage your mail! http://www.topica.com/partner/tag02/register ==^================================================================ IMPORTANT NOTICE: This e-mail and any attachment to it is intended only to be read or used by the named addressee. It is confidential and may contain legally privileged information. No confidentiality or privilege is waived or lost by any mistaken transmission to you. If you receive this e-mail in error, please immediately delete it from your system and notify the sender. You must not disclose, copy or use any part of this e-mail if you are not the intended recipient. The RTA is not responsible for any unauthorised alterations to this e-mail or attachment to it.