It's probably not the fastest piece of code you'll ever run, but my gut
tells me its faster than introspecting the metadata and looping through
that. Plus in the elegance department, I think its the lesser of two evils.
Ben Nadel is always running intricate performance tests comparing different
bits of code. I wonder if he'd be interested in this case.
Baz
On 10/23/07, Mark Mandel <[EMAIL PROTECTED]> wrote:
>
>
> That's a very cute trick!
>
> I wonder how fast it runs ;o)
>
> Mark
>
> On 10/24/07, Baz <[EMAIL PROTECTED]> wrote:
> > Here she is:
> >
> > <!--- THE CFC --->
> > <cfcomponent output="false">
> > <cffunction name="dynamicArgs" access="public">
> >
> > <cfset var func = variables['test'] />
> >
> > <cfset var ExecuteMe="" />
> >
> > <cfset var currentIndex="" />
> >
> > <cfloop from="1" to="#ArrayLen(arguments)#"
> index="currentIndex">
> > <cfset ExecuteMe=ListAppend(ExecuteMe,
> > '''#arguments[currentIndex]#''') />
> > </cfloop>
> >
> > <cfset ExecuteMe="func(#ExecuteMe#)" />
> >
> > <cfreturn evaluate(ExecuteMe) />
> > </cffunction>
> >
> > <cffunction name="test" access="public">
> > <cfargument name="test" type="string" required="Yes" />
> >
> > <cfreturn arguments />
> > </cffunction>
> > </cfcomponent>
> >
> > <!--- INDEX FILE --->
> > <cfset TestObj=createobject('component', 'test') />
> > <cfdump
> >
> var="#TestObj.dynamicArgs('DynArg1','DynArg2','DynArg3','DynArg4','DynArg5')#">
> >
> > I expect the next dot release of transfer to be dedicated to me! HAHAHA!
> > Just kidding.
> >
> >
> > Baz
> >
> >
> > On 10/23/07, Mark Mandel <[EMAIL PROTECTED]> wrote:
> > >
> > > Nah, I wouldn't 'cause I'm mean like that ;o)
> > >
> > > If it worked, I would be interested, as I'm sure many other people
> would.
> > >
> > > Let's see whatcha got ;)
> > >
> > > Mark
> > >
> > > On 10/24/07, Baz < [EMAIL PROTECTED]> wrote:
> > > > Hey Mark, what if I told you I figured out a way to do it? Would you
> > blog
> > > > about it?
> > > >
> > > >
> > > >
> > > >
> > > > On 10/23/07, Mark Mandel < [EMAIL PROTECTED]> wrote:
> > > > >
> > > > > No, I said it won't let you do it *dynamically*, so you can't go:
> > > > >
> > > > > -- added to A.cfc ---
> > > > > <cffunction name="dynamicArgs" hint="" access="public"
> > > > > returntype="void" output="false">
> > > > > <cfscript>
> > > > > var func = variables["test"];
> > > > >
> > > > > func(argumentCollection=arguments);
> > > > > </cfscript>
> > > > > </cffunction>
> > > > >
> > > > > and then try and call dynamicArgs like:
> > > > >
> > > > > <cfscript>
> > > > > a.dynamicArg("dynamic arguments");
> > > > > </cfscript>
> > > > >
> > > > > It bombs out, as the argument collection is looking for a struct
> with
> > > > > named keys, not 1, 2, 3 etc.
> > > > >
> > > > > Make more sense now?
> > > > >
> > > > > Mark
> > > > >
> > > > > On 10/24/07, Baz <[EMAIL PROTECTED] > wrote:
> > > > > > Mark, what do you mean "it won't allow you pass in unnamed
> > arguments"?
> > > > You
> > > > > > did: func("dynamic");
> > > > > >
> > > > > > Baz
> > > > > >
> > > > > >
> > > > > > On 10/23/07, Mark Mandel <[EMAIL PROTECTED]> wrote:
> > > > > > >
> > > > > > >
> > > > > > > Looking into this some more, this won't allow you to pass in
> > unamed
> > > > > > > arguments dynamically, such as from oMM... so maybe it's not
> as
> > useful
> > > > > > > as I had originally thought.
> > > > > > >
> > > > > > > Mark
> > > > > > >
> > > > > > > On 10/23/07, Mark Mandel < [EMAIL PROTECTED]> wrote:
> > > > > > > > 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
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > E: [EMAIL PROTECTED]
> > > > > > > W: www.compoundtheory.com
> > > > > > >
> > > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > E: [EMAIL PROTECTED]
> > > > > W: www.compoundtheory.com
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > E: [EMAIL PROTECTED]
> > > W: www.compoundtheory.com
> > >
> > >
> >
> >
> > >
> >
>
>
> --
> 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
-~----------~----~----~----~------~----~------~--~---
