On Monday, Sep 30, 2002, at 17:55 US/Pacific, Nat Papovich wrote: > Unfortunately though, Rob's really long index doesn't appear to use > Fusebox > 3's "core file", which I assume, is the "complex machinery" you > mention, > Sean. In pre-FB3, there is very little to no machinery used, so long > cfswitch statements are the result of the poor design of whoever wrote > unfortunate Rob's code, not some implied Fusebox architectural path.
Thanx for clarifying. I need to go back and read that FB3 book again! :) I was thinking more along the lines of the impact all the included files had on the code size - the "core files" *are* machinery. However, if you're reassuring me that with FB3, the 64k limit is unlikely to be hit then that is even better to know - after all, it would not be very encouraging if "large Fusebox applications" (whatever they may be - we've had discussions before about 'what is a large application?') simply failed on CFMX due to code size. > I have encountered this same limitation in CFMX/Java in a really long > custom > tag written by (surprise) someone else. Sean, do you know if this (64k) > limitation is something that can be addressed by Macromedia? Or is it > inherent to Java? Or... ? It is inherent in Java's virtual machine - the offset on a jump is 16 bits and that causes a 64k limit. The CFMX compiler tries to work around this in some cases by figuring out that it can rearrange code, but not all files are amenable to this. An Architect's View -- http://www.corfield.org/blog/ Macromedia DevCon 2002, October 27-30, Orlando, Florida Architecting a New Internet Experience Register today at http://www.macromedia.com/go/devcon2002 ______________________________________________________________________ Get the mailserver that powers this list at http://www.coolfusion.com FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/[email protected]/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
