Okay... amazing what comes out when you actually test something out.
I don't know *how* this works, but apparently it does.
I wrote a quick CFC called 'A' It looks like:
<cfcomponent output="false">
<cffunction name="init" hint="Constructor" access="public"
returntype="A" output="false">
<cfscript>
instance = StructNew();
instance.test = "test";
return this;
</cfscript>
</cffunction>
<cffunction name="dynamic" hint="" access="public" returntype="void"
output="false">
<cfscript>
var func = variables["test"];
var ret = 0;
func("dynamic");
</cfscript>
</cffunction>
<cffunction name="getInstance" hint="" access="public"
returntype="struct" output="false">
<cfreturn instance />
</cffunction>
<cffunction name="test" hint="" access="public" returntype="void"
output="false">
<cfargument name="test" hint="" type="string" required="Yes">
<cfscript>
instance.test = arguments.test;
</cfscript>
</cffunction>
</cfcomponent>
First things first:
<cfscript>
a = createObject("component", "A").init();
</cfscript>
<cfdump var="#a.getInstance()#">
Dumps out:
TEST test
Next...
<cfscript>
a.test("thing");
</cfscript>
<cfdump var="#a.getInstance()#">
Dumps out:
TEST thing
Next.. and the weird one:
<cfscript>
a.dynamic();
</cfscript>
<cfdump var="#a.getInstance()#">
Dumps out:
TEST dynamic
What the? This is very cool, but I don't get it! The setting of the
function to a local var scope variable still allows it access to the
parent CFC's instance scope... and lets it change it as it needs to.
This will be very handy for things like onMM, but I'm totally shocked
it actually works...
So guess this was actually the way to go.
Bizarre!
Mark
On 10/23/07, Baz <[EMAIL PROTECTED]> wrote:
> Hey Brian, you are right that the problem could be solved using a convention
> of always using the method name as the argument name, or even deciding on a
> single generic argument name like "Value". But imagine if you were building
> a shared object that will be used by other members of your team, in my case
> a generic data object that can either pull from the variables.instance
> scope, or, if so defined, can use a custom function to set the value. Well
> you could teach everyone a convention/methodology to achieve this, but why
> not make it as intuitive as possible and just send a single un-named
> argument, as any setter method expects. That way your coders don't have to
> remember random syntax and can focus on the core of the problem. It just
> makes the user experience better.
>
> On an un-related side-note, I think this is the first time I've noticed TAG
> syntax not being able to accomplish something that SCRIPT syntax can -
> usually its the other way around.
>
> Baz
>
>
>
>
> On 10/22/07, Brian Kotek <[EMAIL PROTECTED]> wrote:
> > Interesting, I hadn't really run into a situation like that before! Most
> of my dynamic method calls tend to be autopopulating beans, or calling a
> method and passing an argumentCollection. Hadn't gotten into chains of
> dynamic method calls (but maybe I will now heh).
> >
> >
> >
> > On 10/22/07, Sean Corfield < [EMAIL PROTECTED]> wrote:
> >
> > >
> > > On 10/22/07, Brian Kotek <[EMAIL PROTECTED]> wrote:
> > > > I'm still a bit fuzzy though on why you would be calling a method
> whose
> > > > arguments you would "never know" the names of.
> > >
> > > I run into that a lot - in dynamic programming you know nothing about
> > > the methods you are calling beyond the name and approximate calling
> > > sequence. I use getMetadata() on the function to find its arguments.
> > > See:
> > >
> > >
> http://org-corfield-cfmx.googlecode.com/svn/trunk/wwwroot/org/corfield/component.cfc
> > >
> > > The call() method handles arbitrary dynamic calls.
> > > --
> > > Sean A Corfield -- (904) 302-SEAN
> > > An Architect's View -- http://corfield.org/
> > >
> > > "If you're not annoying somebody, you're not really alive."
> > > -- Margaret Atwood
> > >
> > >
> > >
> >
>
>
> >
>
--
E: [EMAIL PROTECTED]
W: www.compoundtheory.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"CFCDev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/cfcdev?hl=en
-~----------~----~----~----~------~----~------~--~---
