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

[Lee Borkman]

Title: Message

Fair enough, Hal,   The challenge for the discerning shopper is always to walk the middle path between eagerly discarding the old in favour of the new on the one hand, and on the other hand, stubbornly holding on to older ways simply because that's the way things have been done in the past.   I thank you guys for doing all this work, and making it available to all of us.  I don't yet know if I'm going to love it all, or merely some of it, or disagree with much of it, but I'm sure glad we have it.  It doesn't do to get complacent ;-)   It's been a pleasure, as always.   Now, tell me more about this "multiplication" idea.  I've been thinking for a while that there has to be a better way than simply adding over and over...   Lee.     ----- Original Message ----- From: hal helms   I can't agree with you on this, Lee. It seems to me having a child set a variable that then overrides the parent's variable leads to unpredictable behavior--hence the funky appellation.What I want--and what FuseQ lets me do--is to abstract common behavior to a parent, not allow a child to "borrow" its parent's fuseactions. Of course, you may want this behavior.   On the matter of there being other ways to do things, well surely that is so. Multiplication can be viewed as super-addition and division as super-subtraction. But I would be hard-pressed to argue against the usefulness of either multiplication or division on this account. Yes, there are other ways of accomplishing the same operation without them, but I, for one, am glad we have them. -----Original Message----- From: BORKMAN Lee [mailto:[EMAIL PROTECTED]] 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...   ==^================================================================ 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 ==^================================================================