Sorry, forgot about this. Well the patch is to add a new attribute to
cfarguments called "passby=value" on all cases where recursion is done
and arrays are passed.

On Jun 4, 5:51 pm, Jamie Krug <[email protected]> wrote:
> +1 :) Mark or Luis: do you happen to have this patch, or maybe point
> me in the right direction?
>
> Thanks!
> Jamie
>
> On May 26, 10:17 am, Shawn <[email protected]> wrote:
>
> > Patch?  Oh yes, please! :D
>
> > Glad to see you guys are working on this.
>
> > On May 24, 8:25 pm, Mark Mandel <[email protected]> wrote:
>
> > > Luis, can you send me a patch with the appropriate place this workaround
> > > needs to be placed inside Transfer?
>
> > > Mark
>
> > > On Fri, May 22, 2009 at 8:22 AM, Kevan Stannard 
> > > <[email protected]>wrote:
>
> > > > There was in good discussion on the array pass by value/reference on 
> > > > this a
> > > > while back:
> > > >http://www.mail-archive.com/[email protected]/msg01670.html
>
> > > > Sean clarified the Adobe ColdFusion behaviour as:
>
> > > > Arrays are actually copy-on-assignment. When you pass an array to a 
> > > > function, it assigns the array to the argument, creating a copy. When 
> > > > you return an
> > > > array from a function, it does not copy it - unless you assign the 
> > > > result to a variable. You can see that here:
>
> > > > <cfscript>
> > > > a = [ 1, 2, 3, 4 ];
>
> > > > function getA() { return a; }
>
> > > > b = getA(); // copies a so b is a separate array
> > > > b[1] = 42; // does not change a
>
> > > > arrayAppend(getA(), 5); // no assignment - a *is* modified
> > > > </cfscript>
>
> > > > On Railo's compatibility; I would be surprised if Railo changed this 
> > > > particular behaviour for performance reasons. I imagine this decision 
> > > > was made to implement it how it should have been done in Adobe CF. I 
> > > > read somewhere that BlueDragon also implements array pass-by-reference 
> > > > (not sure).
>
> > > > Perhaps the problem is not with Railo, perhaps Adobe should implement:
> > > > <cfargument name="myArray" type="Array" passby="reference" />
>
> > > > I do want all of the CFML engines to implement fundamental language 
> > > > behaviour in the same way, but I don't see a problem in this particular 
> > > > case.
>
> > > > Fortunately we have a CFML steering committee now which should 
> > > > hopefully maximise compatibility with CFML engines.
>
> > > > 2009/5/21 Dan Wilson <[email protected]>
>
> > > >> You knowm I am of two minds about this.  The engineer in me is all 
> > > >> about a
> > > >> more performant engine. I've made some design mistakes I wish I could 
> > > >> fix,
> > > >> for performance, for extensibility or for the good of the children...
> > > >> whatever. Mistakes happen.
>
> > > >> However, for Railo to change the way CFML works, and then tout 
> > > >> themselves
> > > >> as faster and better is a little bit rich. Sure you can be 
> > > >> faster/better if
> > > >> you don't implement everything ColdFusion does. But you aren't fully
> > > >> competing then either, are you?
>
> > > >> Take Chris's example, the xe.formaction='whatever'. Sure this is 
> > > >> slower to
> > > >> look up. Sure if I was writing an engine for pure speed I'd try to not
> > > >> support it, heck it affects EVERY variable lookup. However, the 
> > > >> standard
> > > >> (good, bad or ugly) has been set for years and ColdFusion supports it. 
> > > >> For
> > > >> Railo to not support it means they are out of compliance with 
> > > >> ColdFusion and
> > > >> I would be very hesitant to use Railo on existing code for that reason.
>
> > > >> In short, I love the idea of Railo and I love the idea of a faster 
> > > >> engine.
> > > >> I don't love Cherry Picking which parts of ColdFusion to support and 
> > > >> which
> > > >> to leave off for performance, then selling yourself based on 
> > > >> performance. If
> > > >> Railo fully implements the ColdFusion spec, without requiring 
> > > >> non-standard
> > > >> CFML attributes, compiler options and the like, then I'll be impressed.
>
> > > >> DW
>
> > > --
> > > E: [email protected]
> > > W:www.compoundtheory.com
--~--~---------~--~----~------------~-------~--~----~
Before posting questions to the group please read:
http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer

You received this message because you are subscribed to the Google Groups 
"transfer-dev" 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/transfer-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to