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 On Thu, May 21, 2009 at 6:19 AM, Chris Peterson <[email protected]>wrote: > > Elliott - I think more that this is one of the reasons that Railo can be as > fast as it is, because they have made what appears to be a more concise > design decision here about how arrays are evaluated. > > So as an example, often times I have seen exit events in MG coded as: > > Xe.formaction = 'whatever'; > > Well, when that gets evaluated, a check has to be done to see if xe is a > structure or not in Adobe's CF, which in itself probably does not take all > that much time, but when its magnified out across every variable you can > see > where the performance implications come in. > > Just wanted to chime in for clarity here, as I don't think this is a bug in > Railo at all, but rather a decision to break from the Adobe convention to > fix a weakness internal to its engine in an attempt at improving > performance. > > Chris Peterson > > > On 5/20/09 11:45 PM, "Elliott Sprehn" <[email protected]> wrote: > > > > > This is absolutely a bug in Railo. Changing this behavior can > > introduce *serious* and subtle thread safety bugs in code that would > > otherwise be thread safe in Adobe CF. > > > > Knowing this I'd be really really hesitant to deploy any application > > on Railo. > > > > - Elliott > > > > On May 20, 6:43 pm, Luis Majano <[email protected]> wrote: > >> After seeing that post, I could not reply to it, so I am adding my > >> answer here > >> > >> Those issues on the recurssion are related with the Array by reference > >> deal. Basically, Adobe CF handles arrays by value and Railo by > >> reference. A topic I don't want to get into because I think arrays by > >> value are basically STUPID. > >> > >> Anyways, you can have a workaround by using "lazy=true" on your > >> relationships so the recursion stops. However, the real solution is > >> to add the compatibility argument to the transfer core when recursing > >> with arrays. > >> > >> Basically when passing arguments by value, you need to add the > >> following metdata to the argument tag: passby="value" > >> > >> <cfargument name="myArray" type="Array" passby="value" /> > >> > >> If you do that, then you can go back to caveman mode and use arrays by > >> value. > >> > >> Luis > > > > > > > > > -- “Come to the edge, he said. They said: We are afraid. Come to the edge, he said. They came. He pushed them and they flew.” Guillaume Apollinaire quotes --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
