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 -~----------~----~----~----~------~----~------~--~---
