|
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.
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...
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. ;-)
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.
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.
==^================================================================
This email was sent to: [email protected]
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
==^================================================================
|
